Debian Linux on an Acer Aspire 2003WLMi (Aspire 2000 series)

(Please send any corrections or suggestions to <ben@callahans.org>)

Note: the last update (06/20/04) is a major, across-the-board list of changes, nearly as comprehensive as the original description. Most devices
now work; for those that do not, there's a light at the end of the tunnel.

However, I still do not recommend this laptop to Linux beginners; the configuration in many cases is still "expert-only".

Summary of components and current status (note that this is all still in process; page will be updated regularly):

Device Type Status Updated Comment
BIOS
 Insyde EFI
 OK
 06/20/04
 Still no way to boot 'Arcade' via its button, but fine otherwise
Power management
 ACPI
 OK
 02/02/04
 No fan/thermal control, no suspend (hibernation works OK, though.)
Synaptics touchpad
 SynPS/2
 OK
 06/20/04
 Works fine in X 4.3.0.1 using the 'synaptics' driver
Graphics card ATI Radeon Mobility 9200 (M9+)  OK
 06/20/04
 Finally! The "ati" driver in XFree86 supports this card, DRI/GLX included
Screen WSXGA+ (1680x1050) OK
 06/20/04
 Does 1280x800 with above driver
Hard Disk Toshiba MK6021GAS (60 GB) OK
 06/20/04
 Even faster than before
DVD/CDRW Matshita DVD-RAM UJ-815A
 OK
 06/20/04
 Works fine, read/write for both CDs and DVDs
On-board Ethernet Realtek RTL8100L
 OK
 06/20/04
 Good speed
Wireless Ethernet
 Intel PRO/Wireless LAN 2100
 OK
 06/20/04
 Works fine using Intel's ipw2100 driver
On-board Sound Card Intel i810 OK
 04/10/04
 Everything except MIDI works (I use Timidity, so that's fine.)
On-board Modem Intel 82801DB AC'97 (winmodem)
 Semi-OK
 02/23/04
 Proprietary driver; requires reloading between uses
PCMCIA/Cardbus ENE Technology Inc CB1410
 OK
 02/15/04
 One of the few things that worked fine without any tweaking
Infrared SMC IrCC Fast Infrared (FIR)
 OK
 03/09/04
 Tested with Palm Pilot; works fine
Firewire TI TSB43AB21 IEEE-1394a-2000
 Unknown
 01/30/04
 Haven't looked at it yet - don't have any equipment for testing!
USB Intel 82801DB OK
 01/30/04
 Works out of the box, including USB2 support
Special keys Acer custom hardware
 Not working
 06/20/04
 Subwoofer/brightness keys work fine; drivers available for other keys

Also see:

Kernel configuration

General notes

Partitioning

This laptop came with a stupidly rigid HD structure, making it generally useless for partitioning (except at the cost of losing several of its features.) Here's the OEM partition layout:

  1. Windows XP Pro
  2. Backup images and other restore files
  3. DOS tools, presumably for recovery purposes
  4. A Linux mini-distro that is a front end for some "mplayer" functionality (CD/DVD/photos/slide show/etc.) tied to the "Arcade" button.
Since  you can only have four primary partitions, and logical partitioning requires you to use one of the first four as the "container" for all the subsequent ones, this neatly brings the average users partitioning options to "none". Any changes will, of course, destroy the "Arcade" functionality (but see my partial solution a bit further down), certainly render useless any of the restore information (since it is sure to "restore" the idiotic partitioning scheme), and require quite a bit of noodling even on the part of experts who aren't quite willing to just flush the entire thing down the drain, wipe everything, and accept the feature loss.

Update, 1/27/04: According to Acer, the two "middle" partitions can be deleted since all their functionality is part of the "rescue" CDs. Better. However, they don't know anything about how their engineers in Taiwan set up the "Arcade stuff" - which means that you lose that nifty feature no matter what changes you make. Worse. Small credit for flexibility, large debit for incompetence (in this case, defined as farming out key functions of your hardware to mysterious unreachable "engineers".)

Initial approach

I wanted to keep the WinXP installation, at least for a while, since a number of the features on this machine seemed new enough that they were unlikely to be supported under Linux (fortunately, with the partial exceptions of the video card/screen and the Synaptics touchpad, this has turned out to be untrue.) I also wanted to keep the "Arcade" partition - so I could explore it and play with it, if nothing else. To make things even more challenging, I already had a complete installation of Debian that I wanted to clone from my old laptop rather than doing a brand-new install. Best of all, I received this machine just a couple of (very busy) days before I had to fly off to Hawaii to teach a Perl class; the largest chunk of time I had to devote to it - and I had to, since I'd be using this machine as an instructional tool while teaching the class - was on the flight out. Fortunately (in some insane sense of the word), the flight from Cincinnati to Honolulu was an uninterrupted 9.5 hour stretch of boredom. As a temporary solution, I took the 40GB HD out of the old Dell laptop, slapped it into the Acer, and was off for that sunny isle in the Pacific.

Of course, most things didn't work - the 2.4.22 kernel had been compiled for completely different hardware. However, three or four iterations of kernel compilation got rid of the issue and brought up a cheeringly high number of the new features. The nicely long battery life allowed me to keep going right up to my own limit of boredom with tweaking (a fairly high point, that) - and, since Linux is a net-enabled phenomenon, there was only so much I could do.

By the time I got into Honolulu and made it to my hotel room, I was pretty exhausted but still game - particularly since the room had a free Ethernet connection. I grabbed the kernel sources for 2.6.0 - it was obvious that some of the newer features were going to require the latest in software - and ran through a compile cycle before heading out to dinner. I was pleasantly shocked to see the config system grab my 2.4.22 configuration options and apply them to the current kernel; for a few moments, I thought that the machine had a little helper gremlin living in it... alas, this was not the case. :) A few more things came to life, notably most of the ACPI system and some features of the Synaptics touchpad.

I spent the week on Oahu working during the day, playing late into the night, and bit-banging in the wee hours of the morning, with some help from my friends in The Answer Gang, particularly Robos who had some good tips on the current hardware and encouragement when I felt like sailing this thing through a nearby window. Kudos and all hail The Gangsters!

By the time I got back home, I'd resolved a number of issues (although not all of them by far.) I'd also had some time to think about the partitioning scheme that I wanted to implement, mostly based on my wanting to a) retain Windows for a while and b) wanting to keep the Arcade stuff in the fourth partition.

Current status

Eh... middlin'. Most systems are up; one or two (notably power management) aren't yet, and a few more haven't even been tested. Actually, I'm rather unhappy with this machine, but not so much that I'd return it (by a small margin.) It's not perceptibly faster than my old 1.7GHz Dell Inspiron despite all the hype about the Centrino, and it has been - as you will see in the following sections - a tremendous pain in the ass to configure. I'm not using the term lightly, either; it's been a huge source of frustration, and setting it up has been like pulling teeth, my worst experience with a machine in all the time I've been using Linux. Considering that I make a part of my living from doing so, am the Technical Editor for Linux Gazette, have been using Linux since 1997 and computers in general since the 1970s, that's saying quite a lot. I would explicitly NOT recommend this computer to anyone who's looking to buy a laptop for Linux; the average Joe would probably have killed either himself, Acer (which has proven almost completely useless for technical support or hardware data), or the machine by now.

On with the saga.

Systems

BIOS

A notable item in all of this is the fact that Acer used EFI instead of BIOS for this machine - their implementation is called "Insyde" (as if there weren't enough mispelld brand names in this world, [sigh].) My lack of familiarity with this added another little unknown factor to the equation in which Terra Incognita was already taking up most of the map... the only problem it has created so far, though, is a minor one having to do with the "Arcade" app. The cute trick to this bit is that you don't have to start Windows to do your multimedia chores: just push the "Arcade" button, and a few seconds later, voila - you have a DVD player, etc. (with Linux and "mplayer" doing all the work behind the scenes!) However, despite the fact that I left "Arcade" in the fourth partition, with exactly the same partition size as previously, pushing the button while the machine is off now produces a "Missing Operating System" message. This is normally an indication of an incorrect pointer from the MBR to the OS boot loader, or a sign of a missing boot loader... however, with EFI doing some unspecified chunk of the process, I'm somewhat lost as to what to do to restore that functionality. I have, however, mapped it in my "/etc/lilo.conf" by copying the stanza from "Arcade"'s "lilo.conf" and modifying the mount paths - so I can still run it by selecting the correct target at the LILO prompt during the boot. I'd like to have it working as it did originally, but - no joy so far.

Update 02/13/04: I've contacted Insyde USA, who have been very cooperative so far (I'll admit it: I baited the hook by offering to write an article about them for the Linux Gazette. Yeah, yeah, I'm a creature of pure evil; what can I say? :) They're contacting their people in Taiwan, and there may yet be a possible resolution; stand by this channel for the latest news.

Update 06/20/04: Acer has not gotten back to me on this. Add to it the fact that my hard drive died and the AC adapter croaked, all in the first few months, and you can judge the quality of this machine and Acer's support for yourself.

Power Management

APM or ACPI? Not much of a choice, I'm afraid.

Linux ACPI still seems to be a Young Science: lots of progress being made daily, exciting stuff... and a pain for those of us who need to use it. This is not a complaint against the ACPI folks - the blessings of heaven upon their heads forever, and may they never skip a semi-colon! - but a grumble by a tired Linux techie. The 2.6.x kernel's APM is broken, I'm sorry to report; firing up Knoppix on this machine, which uses the 2.4.x kernel (console mode only; amazingly, the "vesa" X server that comes with it works! - but only for a few minutes, after which it locks the machine solid) allows me to use "apm -s" (suspend) and "apm -S" (standby). 2.6.0 does not; in fact, it won't even read the battery charge state under APM. ACPI gives me at least that much... so, that's what I'm using right now. Highly unsatisfying, to say the least; a laptop that won't sleep or suspend is lacking a large part of its utility.

I've also taken a look at "swsusp" - yet another brilliant but not-quite-ready idea from the Linux community. This gadget introduces a "hibernate" mode to Linux, where the machine state is saved to swap - and is restored on the next boot! In fact, if you have a laptop with a "normal" video card (e.g., one that's fully supported by a common X server), I can't recommend this highly enough: there are many people using it, and are happy as larks. However, the proprietary "fglrx" server from ATI knocks this machine out of the range of possibility. "L'shana Haba'a Bi'rushalayim" ("Next year in Jerusalem"), as some of my relatives would wish/say.

Update 02/02/04: Ugh. This is a minor screw-up on my part, and I think the note should go here, but... anyway. Something, "acpid" if I recall correctly, fails to launch with a message that contains the word "bogus" if the new "sys" directory does not exist. [sigh] This is what happens when you troubleshoot a whole hell of a lot of problems late at night and don't keep notes right at the time; suffice it to say that, with the 2.6.x kernels, you need to create "/sys" and mount it with "sysfs" as the system type, or Bad Things Will Happen. Relevant line from my "/etc/fstab":

# <fs>      <mt_point>     <type>    <options>   <dump>  <pass>
none        /sys           sysfs     auto        0       0

Update 02/18/04: Did a little more experimenting to make sure; yep, APM is very seriously broken. Yeah, "apm -S" actually works... but what you pay for it is a) both the WLAN and the Bluetooth buttons light up and can't be turned off (I didn't bother checking the effect on the actual interfaces), b) "apm -s" locks the machine 7 times out of 10, c) no battery percentage display - and no way to get it, since the APM driver itself doesn't even recognize that a battery exists, and, "best" of all, d) it sometimes goes into a "hung" state that survives between reboots, even if another OS is booted between those, that turns off the keyboard. Removing the battery and powering the system down is the only answer. Given that the default mode in the 2.6 kernel is to rotate the last two kernels, and that both of mine had APM compiled in... well, good thing that I had my Knoppix CD close by. Oh, and my LNX-BBC CD as well - Knoppix is a huge pain when it comes to running chrooted LILO, which is what you need to do when you're fixing boot problems.

Update 06/20/04: ACPI has gone through a number of changes between the time that the above was written and now. Although I have not followed the progress of it closely and don't know whether 'sleep' works yet (simple testing with "/proc/acpi/sleep" and "/sys/power/state" imply that it doesn't), 'hibernate' via "swsusp" seems to work fine. This is configured in the kernel, in the power management section.

There's also a slight issue with the percentage-of-charge display in IceWM (however, the error is definitely in the ACPI subsystem): the system randomly switches between displaying 83% and 100% indication for a fully charged battery between hibernations. Not a big thing, but it's less than optimal behavior.

Hard Disk

No special tweaking was required here, but I did want to point out that I'm quite pleased with the speed provided by the UDMA100 mode:
# hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads:   72 MB in  3.05 seconds =  23.63 MB/sec
Update 06/20/04: For whatever reason - whether it's the new HD or better buffering in the kernel - the disk is now somewhat faster:
/dev/hda:
 Timing buffered disk reads:   80 MB in  3.06 seconds =  26.13 MB/sec

Synaptics module/driver

Other than the video hardware, this is the part of this machine that gave me the most trouble at the start. In fact, it's still giving me trouble - under X, it's so twitchy that using the pad when your skin is  very dry results in tons of spurious signals - meaning that just moving a cursor across the screen is perceived as a series of rapid taps... with predictable results. I'll be tweaking the relevant values (Option "FingerLow"/Option "FingerHigh") in my "/etc/X11/XF86Config-4" as part of my next round of fixes.

There are two major - and unrelated - parts to dealing with this thing, console and X. First, though, you have a decision to make: if you just want the basic crude PS/2 functionality, just select the PS/2 driver in the kernel and you're done. However, you will not be able to double-tap the pad for button emulation - you'll have to pound those huge clunky buttons that Acer chose to use. Don't like the idea? Want all the cool modern goodies? Follow me. It's not going to be too wild of a ride, I promise... it was a real pain in the fundament to gather this info initially, but it's not too bad otherwise.

First, the relevant kernel configuration (under "Input device support"):
<*> Event interface
<M> Event debugging
[*] Mice
<*>   PS/2 mouse
[*]     Synaptics TouchPad
Note that the comment for the last entry says "The gpm program is not yet able to interpret the data from this driver, so if you need to use the touchpad in the console, you have to say N for now." Not quite true - if you go to Dmitry Torokhov's page, you'll find GPM v 1.20 which works just fine. So far so good, right? Right. Actually, in the console, it works fairly smoothly, although I was unable to get the tap functions working. Now, - [insert deep theatrical sigh here] - let's talk about X...

The 'synaptics' kernel option, above, will be sending data. Obviously, something needs to catch and interpret that data. For the console, we have GPM; in X, we have... the plain old PS/2 module, which isn't what we want for our brand new "synaptics" kernel driver - so Peter Österlund has an FAQ page that provides a link to the driver we need and much other good info besides. Download, compile, install. Note: I've seen some noise and smoke in various places implying that it's possible to make that Synaptics scroll button (the round gadget between the left and right buttons) work; it's all a base canard intended to frustrate us poor techies, nothing more. <grumble> (If you manage the trick, please let me know.)

Instead of the old 'double-tap to paste' method, the X 'synaptics' driver uses two-finger tapping, meaning that you actually tap the pad with two fingertips at the same time, something that only took a few minutes to adapt to.

As always, I set up GPM with the "repeater" option so that there's no conflict between the console and X; the latter simply uses the data sent by GPM. Here's how it's done (this is my "/etc/gpm.conf"):
device=/dev/psaux
responsiveness=30
repeat_type=ms3
type=ps2
append=""
sample_rate=50
Now, just use the "/dev/gpmdata" device in your X config file (see next section), and you're good to go.


Update 02/03/04: It's a bit better if not yet perfect; setting the "FingerLow" value to 15 instead of the original 25 made it a bit less touchy.

Update 02/13/04: After some serious digging, it's either working well or I've become numb to the bad stuff. :) The "FingerHigh" value detects the initial touch; 35 seems to be a good compromise between ignoring accidental brushing of the pad and not having to really smack it. "FingerLow" determines when the finger comes off the pad; 25 actually works fine once "FingerHigh" is properly set. Anything below that results in unintentional dragging, highlighting, etc. The main thing is, once you understand the parameters, to set it for your own preferences - but 35/25 seems to be a really good starting point.

Update 06/20/04: The "synaptics" driver in XFree86 4.3.0.1 seems to be handling this touchpad just fine - including (to my surprise when I accidentally discovered it) the scroll button! However, the console still requires Dmitry's GPM - at least that's what I'm using, and it works fine (no double-tapping or tap-dragging in the console, though.)

Graphics card / Screen

Framebuffer

Initially, the Acer didn't want to know from this console stuff and gave me a choice of either a blank screen with "vga=0x317" and the like or some HUGE text mode with 80x25 being the "best" choice. Yechh. However, after a little kernel config tweaking, I came up with this:

[*] Support for frame buffer devices
<*>   VESA VGA graphics support
    Console display driver support  --->
             [*]   Video mode selection support
             <*> Framebuffer Console support
    Logo configuration  --->
             [*] Bootup logo
             [*]   Standard 16-color Linux logo
             [*]   Standard 224-color Linux logo
I also happened to see someone on a Debian list mentioning that the "vga=" syntax is deprecated in the 2.6 kernels, and the new format is "(H)x(V)-(bpp)", so the "append" line in my "/etc/lilo.conf" now reads
append="quiet acpi=on video=vesafb:1024x768-16"
I've left "vga=0x317" in there as well; it doesn't seem to hurt anything, and I may yet run into some odd boot scenario...

The result of all of this is that I have a very cute little penguin in the upper left corner during the boot, and quite a nice-looking console, just like I'm used to having.

Update 02/16/04: Turns out that "new" vga= syntax doesn't do much of anything. I'm back to  
append="quiet acpi=on hdc=ide-scsi"
and the framebuffer video is still fine.

X server

Despite a number of resources on the Net swearing on a stack of Necronomicons that the "ati" X server works for the Radeon 9200, I have not found it to be so. In fact, I think the lot of lying scoundrels just did that so they could imagine me struggling uselessly for their amusement... what, too paranoid? OK. :) Anyway, with "ati" I never managed to get past the famous "TRANS(SocketUNIXConnect) () can't connect: errno = 111" error, which is the server crying that can't find any appropriate hardware. The "ati" server is part of the "xserver-xfree86" package, for those who feel like trying it on their own; "vesa" - that being what Knoppix seems to be using - also shows some promise. Please do let me know if you manage to get any of those working; I've even tried the bleeding-edge versions from apt-get.org - nope, no luck.

ATI has a fairly liberal policy with regard to releasing their drivers to the Open Source community; as I understand it, they keep these things proprietary until the board is off their "latest greatest" list - about a year, normally - and then release the specs. It's not perfect, but it's admittedly a lot better than nothing - and they were doing this long before other OEMs even recognized the word "Linux". So, what the heck... I just wish the thing worked a little better. :( Under Windows, this hardware/screen combo theoretically does 1680x1050 - mind you, when I tried setting it to that resolution in Windows, I got the equivalent of X's "VirtualScreen" - a desktop that you could scroll around through a 1280x800 window. [shrug] As a talent-free but heavily-hyped country songstress caroled, "that don't impress me much"; in Linux, I can do a VirtualScreen a few miles on a side if I want to - this has nothing to do with resolution.

Package from ATI: fglrx-glc22-4.3.0-3.7.0.src.rpm

If you're using Debian, you'll need to convert that RPM to a DEB; the "alien" utility handles that flawlessly. Once that's done, here are the steps:
  1. Become root.
  2. Install the package:
    dpkg -i fglrx-glc22_4.3.0-4.7_i386.deb
  3. "cd" into "/lib/modules/fglrx/build_mod/2.6.x" and run "make".
  4. "cd" up one level and run "./make.sh".
  5. "cd" up one more level and run "./make_install.sh".
Note the last three steps carefully; you'll need to repeat them every time you recompile your kernel!

Next, you'll need to run the "fglrxconfig" utility. This is the only right way (according to ATI) to build your new X config file; I'd say that this is the way you should build it initially and then tweak to suit. Here's the XF86Config-4 from my own "/etc/X11"; the lines shown below are the ones that you might have to "adjust to suit". The comments here are not the same as the ones in the file - I simply wanted to point out where and why you may want or need to change these, as well as show the "synaptics" section which should just be copied wholesale into the "InputDevice" section (the original "PS/2" section in there should be commented out.) By the way, note that loading "GLcore", which you do need, is going to generate a series of warnings on your launch console:
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_clip.o":  No symbols found
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_norm.o":  No symbols found
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_xform.o":  No symbols found
Skipping "/usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_vertex.o":  No symbols found
There doesn't seem to be anything harmful in it. The problem is in the lib itself; running "nm" on it shows that it indeed is missing symbols in those routines. [shrug]

And now, a few comments from our sponsor: 
Section "dri"
# Allow access to OpenGL to all users
    Mode 0666
EndSection

Section "Module"
# Make sure that all of these are present
    Load        "dbe"           # Double buffer extension
    Load        "GLcore"        # GL core
    Load        "glx"           # GLX module
    Load        "dri"           # Direct rendering module
EndSection

# This section enables the "synaptics" driver and sets its parameters
Section "InputDevice"
  Driver        "synaptics"
  Identifier    "Mouse1"
  Option        "Device"        "/dev/gpmdata"         # This comes from the GPM repeater
  Option        "Protocol"      "auto-dev"
  Option        "LeftEdge"      "1900"
  Option        "RightEdge"     "5400"
  Option        "TopEdge"       "1900"
  Option        "BottomEdge"    "4000"
  Option        "FingerLow"     "25"                   # I'll probably be changing this one...
  Option        "FingerHigh"    "30"                   # ...and maybe this one too.
  Option        "MaxTapTime"    "180"
  Option        "MaxTapMove"    "220"
  Option        "VertScrollDelta" "100"
  Option        "MinSpeed"      "0.02"
  Option        "MaxSpeed"      "0.18"
  Option        "AccelFactor" "0.0010"
  Option        "SHMConfig"     "on"
EndSection

# This is from the ATI "fglrx" configuration section
Section "Device"
    Identifier                          "ATI Graphics Adapter"
    Driver                              "fglrx"
# ### generic DRI settings ###
# === disable PnP Monitor  ===
    #Option                              "NoDDC"
# === disable/enable XAA/DRI ===
    Option "no_accel"                   "no"            # Enable acceleration
    Option "no_dri"                     "no"            # Enable DRI
# === misc DRI settings ===
    Option "mtrr"                       "off"           # disable DRI mtrr mapper, driver has its own code for mtrr
                                                        # NOTE: you'll want to turn off "MTRR" in the kernel - otherwise,
                                                        # there's a conflict (see /var/log/messages) between the two, at
                                                        # least on my system. It's not a fatal conflict, however.

# === Misc Options ===
    Option "UseFastTLS"                 "2"
    Option "BlockSignalsOnLock"         "on"
    Option "UseInternalAGPGART"         "yes"                # Some people have reported having to disable
                                                             # this and use the system AGP; in my case, "yes"
                                                             # works fine.
    Option "ForceGenericCPU"            "no"
    BusID "PCI:1:0:0"    # vendor=1002, device=5961          # This is the BusID for the ATI from "lspci"
    Screen 0
EndSection

Here is the relevant kernel configuration:
<M> /dev/agpgart (AGP Support)
<M>   Intel 440LX/BX/GX, I8xx and E7x05 chipset support
<M>   NVIDIA nForce/nForce2 chipset support
[ ] Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
Note that I load none of the above modules; after much research, it turns out that ATI's documentation for this server specifically tells you to disable in-kernel DRM/DRI, or at least load them dynamically and after the "fglrx" module. I found that completely disabling them (i.e., not loading any of the modules) made no difference whatsoever, but left them compiled so I could test different possibilities.

I still have a problem with X, though. In short, here it is:
ben@Fenrir:/etc/X11$ glxinfo|grep direct
direct rendering: No
I've tried pretty much everything I can think of - reading the ATI docs, grepping the Web, looking for any related issues, waving a chicken over my head while chanting the Acer manual backwards in Sanskrit... "direct rendering" remains at "no". According to all that I see in the docs, this Should Not Be - and indeed, my favorite Linux program, the FGFS flight simulator, now sucks large rocks through a bendy straw when it comes to speed - e.g., a rudder correction takes about 5-7 seconds to actually happen. I submit that this is not the way to fly an airplane (not if you want to live, that is. I mean, Orville and Wilbur's controls worked better than that!) "fgl_glxgears" refuses to even talk to me:
ben@Fenrir:/etc/X11$ fgl_glxgears 
Error: couldn't get fbconfig
I've removed all GL-relevant libs from "/usr/X11R6/lib/modules/extensions" as the ATI docs recommend, and have re-run "ldconfig". I've gone so far as to uninstall all the GL-relevant libs I could (a lot of the KDE programs depend on "xlibmesa3-gl" and "xlibmesa3-glu", so those are still here. I can only hope that it's not what's causing the problem.) Interestingly enough, "glxgears" works fine:
ben@Fenrir:~$ glxgears
1616 frames in 5.0 seconds = 323.200 FPS
1500 frames in 5.0 seconds = 300.000 FPS
1580 frames in 5.0 seconds = 316.000 FPS
Worse yet, the X log says that DRI, hardware acceleration, and all that other happy horseshit is enabled! I wish X would make up its mind, already... in my favor, that is. This is one issue I'll be hunting down for sure; I'm going for a private pilot's license these days, and I need my FGFS. :)


Update 17:22 1/30/2004: Oh... this is just stupid. And indicative of how much effort and care was put into the job by ATI. Above, I mentioned the fact that running "fgl_glxgears" crashes with 
Error: couldn't get fbconfig
So, I decided to do a little detective work and see why it crashes:
ben@Fenrir:~$ strace /usr/bin/X11/fgl_glxgears 2>&1 | less
execve("/usr/bin/X11/fgl_glxgears", ["/usr/bin/X11/fgl_glxgears"], [/* 28 vars */]) = 0
uname({sys="Linux", node="Fenrir.Thor", ...}) = 0
brk(0)                                  = 0x804d000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.preload", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/mmx/cmov/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/mmx/cmov", 0xbffff038) = -1 ENOENT (No such file or directory)
open("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/mmx/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/mmx", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/cmov/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/cmov", 0xbffff038) = -1 ENOENT (No such file or directory)
open("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/mmx/cmov/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/mmx/cmov", 0xbffff038) = -1 ENOENT (No such file or directory)
open("/home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/mmx/libGL.so.1", O_RDONLY) = -1 ENOENT (No such file or directory)

[lots of similar lines elided]
What the heck??? It looks like someone compiled "fgl_glxgears" by linking to a bunch of libs in their home directory instead of their normal locations. Say - they all look like the ones in "/usr/X11R6/lib"!
ben@Fenrir:~$ mkdir -p /home/mtippett/perforce/mtippett-dk/lnx/gcc/3.2/lib/tls/i686/mmx/
ben@Fenrir:~$ ln -s /usr/X11R6/lib $_/cmov
ben@Fenrir:~$ fgl_glxgears
It works fine now. <sigh> I should probably let ATI know about this, since they provide "fgl_glxgears" as a compiled binary... if I don't run out of patience with the usual hassle inherent in contacting a company in order to give them something useful, or fix their own bloody sloppy work. (Impatient? Me? Yeah. Incompetence, especially in dealing with the public, drives me up a wall.)

Update 18:17 1/30/2004: YESSSS!!! I am great,  I am powerful, my foes fear me, women write me passionate love poetry and send me flowers... but anyway, besides all that, I've done it - got GLX working on my system, and my FGFS flight simulator is up to full speed and its (better than) former glory.

What led me to the solution was 1) a careful re-grepping of the Net with Google set to "stun" (I used 'direct rendering: No' as the search string, with the quotes included to make it into a phrase lookup), 2) tracking a reference which led me to the absolutely wonderful DRI-troubleshooting Wiki page which 3) walked me through a step-by-step process of finding out which version of the GL libs my programs were using. Hurrah! It turned out to be the nVidia GLX libs (recall that I cloned this from my Dell laptop; the video hardware there was an nVidia card) - which the highly toxic nVidia installer had scattered all throughout my system, including doing things like redirecting the original symlinks to its own lib versions.

So, before I forget - here's where I found all the stuff to be deleted. If you're having the same problem, just run "ldd <glx_program>", e.g. "ldd glxinfo" and look at the GL library locations - they should all be in "/usr/X11R6/lib", or symlinks that point there (a few of those are in "/usr/lib", but be sure to double-check.) If you see them elsewhere, note the location and move them out of there (I like to create a subdir in "tmp" called "usr_lib_tls" or whatever the location is and move the files into it), then double-check to see what's being used now. If you get a missing dependency, you most likely had a replaced symlink; look for the lib being referred to in /usr/X11R6/lib and link to it as necessary (see the libGL example, just below.)

These were the "bad" libs:
/usr/lib/libGLcore.so.1
/usr/lib/libGLcore.so.1.0.5328
/usr/lib/libGL.la
/usr/lib/libGL.so.1
/usr/lib/libGL.so.1.0.5328

/usr/lib/tls/libGLcore.so.1
/usr/lib/tls/libGLcore.so.1.0.5328
/usr/lib/tls/libGL.la
/usr/lib/tls/libGL.so
/usr/lib/tls/libGL.so.1
/usr/lib/tls/libGL.so.1.0.5328
Note that removing "/usr/lib/libGL.so.1", which was a symlink to nVidia's "libGL.so.1.0.5328" would have broken a number of programs that rely on finding it in "/usr/lib". However, that's an easy fix:
ben@Fenrir:~$ su -c 'ln -s /usr/X11R6/lib/libGL.so.1 /usr/lib/libGL.so.1'
Done! Now, "glxinfo" gives us Good Mojo:
name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: ATI
client glx version string: 1.3
client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_ATI_pixel_format_float, 
    GLX_ATI_render_texture
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: MOBILITY RADEON 9000 DDR x86/SSE2
OpenGL version string: 1.3 (X4.3.0-3.7.0)
OpenGL extensions:
    GL_ARB_multitexture, GL_EXT_texture_env_add, GL_EXT_compiled_vertex_array, 
    GL_S3_s3tc, GL_ARB_occlusion_query, GL_ARB_point_parameters, 
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
    GL_ARB_transpose_matrix, GL_ARB_vertex_blend, GL_ARB_vertex_buffer_object, 
    GL_ARB_vertex_program, GL_ARB_window_pos, GL_ATI_element_array, 
    GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_ATI_map_object_buffer, 
    GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once, 
    GL_ATI_vertex_array_object, GL_ATI_vertex_attrib_array_object, 
    GL_ATI_vertex_streams, GL_ATIX_texture_env_combine3, 
    GL_ATIX_texture_env_route, GL_ATIX_vertex_shader_output_point_size, 
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, 
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint, 
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays, 
    GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal, 
    GL_EXT_secondary_color, GL_EXT_separate_specular_color, 
    GL_EXT_stencil_wrap, GL_EXT_texgen_reflection, GL_EXT_texture3D, 
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, 
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine, 
    GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_texture_rectangle, 
    GL_EXT_vertex_array, GL_EXT_vertex_shader, GL_HP_occlusion_test, 
    GL_NV_texgen_reflection, GL_NV_blend_square, GL_NV_occlusion_query, 
    GL_SGI_color_matrix, GL_SGIS_texture_edge_clamp, 
    GL_SGIS_texture_border_clamp, GL_SGIS_texture_lod, 
    GL_SGIS_generate_mipmap, GL_SGIS_multitexture, GL_SUN_multi_draw_arrays
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
----------------------------------------------------------------------
0x23 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x24 24 tc  0 24  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x25 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x26 24 tc  0 24  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x27 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x28 24 tc  0 24  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x29 24 tc  0 24  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x2a 24 tc  0 24  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x2b 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2c 24 dc  0 24  0 r  .  .  8  8  8  8  0 24  8 16 16 16 16  0 0 Slow
0x2d 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x2e 24 dc  0 24  0 r  .  .  8  8  8  8  0 24  0 16 16 16 16  0 0 Slow
0x2f 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x30 24 dc  0 24  0 r  .  .  8  8  8  8  0 24  8  0  0  0  0  0 0 None
0x31 24 dc  0 24  0 r  y  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
0x32 24 dc  0 24  0 r  .  .  8  8  8  8  0 24  0  0  0  0  0  0 0 None
As a friend of mine says, "Woo and Hoo!"

Update 06/20/04: "ati" driver works fine - with caveats. Enabling DRI/GLX makes the return from hibernation hang at the last moment, just as the screen is switching from the console back to the GUI... or at least it did. Here's the entirety of War and Peace (the Reader's Digest Condensed version):

1) I switch over to using "ati" ("radeon" turns out to be just a wrapper for it). DRI/GLX, of course, fails - since ATI's "fglrx" server used its own version.
2) I recompile/fix the kernel to provide the right DRM/DRI stuff:
Device drivers/Character devices:
	<M> /dev/agpgart (AGP Support)
	<M>   ATI chipset support
	<M>   Intel 440LX/BX/GX, I8xx and E7x05 chipset support
	[*] Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
		<M>   ATI Rage 128
		<M>   ATI Radeon
3) I download and install all the GLX-related packages: 
xlibmesa-dri - Mesa 3D graphics library modules [XFree86]
xlibmesa-gl - Mesa 3D graphics library [XFree86]
xlibmesa-glu - Mesa OpenGL utility library [XFree86]
Play with it for a bit, resolving errors as they come up - my GLX testing script comes in really handy here:
------------------------------------------------------------------------------------------------
#!/bin/bash
# Created by Ben Okopnik on Sun Jun 13 11:03:00 EDT 2004

p="Press 'q' to quit"
LIBGL_DEBUG=verbose glxinfo 2>&1|less -P"$p"
dmesg|egrep -i 'agp|drm'|less -P"$p"
less  -P "Press 'n' to see the next warning or error" -ip "\(WW|EE\)" /var/log/XFree86.0.log
------------------------------------------------------------------------------------------------
...and now DRI/GLX works. Sorta. That is, it makes the "return from hibernation" hang, hard. So, I

1a) Download and install the latest DRI/GLX binaries, etc. from http://dri.sourceforge.net; enable DRI/GLX, run, and... same problem. Except now it's much worse: any half-hearted attempt to restore X back to the way it was causes the system to hang whenever X is invoked. This now means that

2a) ...my system is now fragile, that is, subject to being broken by the next update that changes anything in X. This is, of course, unacceptable - so I

3a) ...download all the packages relevant to the X base installation, DRI, and GLX:
xfree86-common_4.3.0.dfsg.1-4_all.deb
xlibmesa-dri_4.3.0.dfsg.1-4_i386.deb
xlibmesa-gl_4.3.0.dfsg.1-4_i386.deb
xlibmesa-glu_4.3.0.dfsg.1-4_i386.deb
xserver-common_4.3.0.dfsg.1-4_i386.deb
xserver-xfree86_4.3.0.dfsg.1-4_i386.deb
x-window-system-core_4.3.0.dfsg.1-4_i386.deb
xlibs_4.3.0.dfsg.1-4_all.deb
libxt6_4.3.0.dfsg.1-4_i386.deb
and reinstall them. I launch X, and...

4a) Hallelujah. Everything works. Best of all, when I accidentally put the machine into "hibernate" with GLX enabled, it now works! (Don't ask me; I just type here.) The GLX/hibernate problem, by the way, has been reported many times on the DRI list - so it wasn't just me. As to it working, however, I may well be unique - and note that I've already done a system upgrade (apt-get upgrade), and it still works. Amazing.

Anybody who wants to repeat this insane tango, go right ahead. Just realize that if your computer blows up or you accidentally open the gate to the Nether Dimensions, I'm not to blame; if Ashtaroth or any of his 10,000 demons come and suck out your kidneys after biting your head off, don't come crying to me.
Oh yeah - you can see my latest XF86Config-4 here.

TV-out

Haven't tried it. This might be a shock to some, but I'm one of those odd ducks who doesn't even have a TV, so have neither the equipment nor the interest.

External Monitor

Again, no idea, but I see no reason that it wouldn't work - other than the usual Acer perversity, perhaps.

Update 06/20/04: A little more data, none of it encouraging (but none indicating definite breakage, either): during my last class, I hooked the Acer to an LCD projector - which refused to cooperate (pounding F5/F6 had no effect.) Rebooting showed the console, hurrah!.... until the machine switched into GUI mode, at which point the projector said "NO SIGNAL" and thumbed its nose at me. True, LCD projectors are finicky buggers, and the odd geometry (1280x800) may have put it off, but...

Ethernet adapter

Pretty basic - I saw what Knoppix loaded (the "8139too") driver, and compiled that in. Voila.

Sound card

The chipset of the sound card works pretty well with both OSS and ALSA. This is one of those places where I must again thank Robos, and add Kapil Hari Paranjape (both of The Linux Gazette Answer Gang) - well done, gentlemen, good advice! If it wasn't for them, ALSA would have remained a deep dark mystery to me; I'd never managed to get it working up till now (due to a small bug in ALSA, it turns out.) The thing to realize is that, even though you can compile all the ALSA stuff statically, it won't work: ALSA expects to load the relevant modules, and if it can't find them, it just drops dead. So, modular compilation - supposedly the wave of the future for Linux anyway - is the way to go.

Relevant kernel config:

<*> Advanced Linux Sound Architecture
<*>   Sequencer support
<M>     Sequencer dummy client
[*]   OSS API emulation
<*>     OSS Mixer API
<*>     OSS PCM (digital audio) API
[*]     OSS Sequencer API
<*>   RTC Timer support
[ ]   Verbose printk
[ ]   Debug
      Generic devices  --->
            <M> Dummy (/dev/null) soundcard
            <M> Virtual MIDI soundcard
            < > MOTU MidiTimePiece AV multiport MIDI
            <M> UART16550 - MIDI only driver
            <M> Generic MPU-401 UART driver
      PCI devices  --->
            <*> Intel i8x0/MX440, SiS 7012; Ali 5455; NForce Audio; AMD768/8111

Update, 2/21/04: I'm back to OSS. ALSA messed up the sound in Quake2 - it kept cycling on and off on about a 1-second loop, made FlightGear very unhappy (lots of error messages regarding sound), and I gave up after trying to fix it for several hours. OSS Just Works - again, except for the MIDI stuff, which didn't work with ALSA either. As I understand it, AC97 cards have been a problem that way ever since the beginning. No big deal; I just use Timidity to do software-based MIDI, and all is good.

Update, 3/09/04: ...and right back to ALSA! OSS turned out to have a score of problems all its own; much of what I thought was an ALSA problem was an Acer Problem (tm). In fact, now that I've upgraded to the 2.6.3 kernel, Quake2 is the only app left that's giving me sound problems: even games like "luola" and "pathological", which previously crashed during sound initialization, are working fine. As to Flight Gear, it worked well after I messed around with it (i.e., I didn't really do anything different - except perhaps recompile the kernel with the same exact sound settings). <shrug> ¿Quien sabe? Anyway, 2.6.3 is a big jump forward in ALSA functionality, so that's where things are now.

Update, 4/01/04: Got Quake working. This is not documented anywhere, I just got there by screwing around with it endlessly and taking some wild guesses. In your "~/.quake2/baseq2/config.cfg", change the line that says

set snddriver "oss"
to
set snddriver "sdl"
The "alsa" driver is broken. So, no, ALSA itself wasn't to blame; just me unable to see the trees for the forest...

Modem

Blah. It's a Winmodem, one of those disgusting creatures that glom onto their host organism and drink its blood... or at least CPU cycles. I don't really have much to report, since I haven't had an occasion to set this thing up yet; the modem I use is part of my Nextel i730 cell phone - I live on a boat anchored a few hundred feet from shore, and phone lines are a bit rare out here. Meanwhile, according to the redoubtable Robos, the creature should work when prodded with the drivers available here. I'm sure I'll be finding out about it Real Soon Now...

Update 2/23/04: Installed "slmodem-2.9.5". It's a little messy - you have to load the appropriate module, then launch a daemon which creates the device (/dev/ttySL0), at which point you can dial out. If you use "wvdial", note that it will require 'Carrier Check = no' in its config file. All of this, as well as the compilation process, is covered in the README included in the package.

My solution to the mess uses shell scripting, "sudo" (required to load the module and create the device), and "icewm"'s key configuration menu. It should not be very different for other window managers, particularly ones that allow you to define shortcut keys (e.g. KDE and "fvwm".) 

# Create the module loader/daemon launcher script, "modemup"
ben@Fenrir:~$  cat <<! > /usr/local/bin/modemup
#!/bin/bash
# Created by Ben Okopnik on Mon Feb 23 10:25:03 EST 2004
modprobe slamr
/usr/sbin/slmodemd /dev/slamr0
!

# Make it executable by everyone but readable and writeable only by owner
ben@Fenrir:~$ chmod 711 /usr/local/bin/modemup

# Make it a bit more secure
ben@Fenrir:~$ su -c 'chown root.root /usr/local/bin/modemup'
Password:

# Make "/usr/local/bin/modemup" executable via "sudo" for the appropriate person or group; see "man sudo"
ben@Fenrir:~$ su -c visudo
Password:

# Create loader/dialer script
ben@Fenrir:~$ cat <<! > /usr/local/bin/dialup
#!/bin/bash
# Created by Ben Okopnik on Mon Feb 23 10:28:51 EST 2004
xterm -geometry 50x10+0+0 -fn fixed -title "Slammr daemon" -e sudo modemup &
sleep 1
xterm -geometry 50x10+0+0 -fn fixed -title "WVDial" -e wvdial &
!

# Make it executable
ben@Fenrir:~$ chmod 755 /usr/local/bin/dialup

# Finally, tie "dialup" to a hotkey in "icewm".
ben@Fenrir:~$ echo 'key "Alt+Ctrl+d" dialup' > ~/.icewm/keys
Restart "icewm", and there you'll be, able to please tall blondes in a single mounting... or something like that, anyway.

Wireless Ethernet

More involuntary dentistry involved (this is all like pulling teeth, with much screaming and wishing for strong pain-killers.) Of course wireless doesn't work - at least not easily. I haven't really had a chance to test it - the only WAP I know of is at the local airport, and when I'm there, I'm too busy for playing with computers (I'm going for my pilot's license.) However, everything that can be done without a WAP, I've done. What this requires is ndiswrap - although you could always go to linuxant.com and pay $20 for a closed-source system, such a deal! Yeah, right. Anyway, download and unpack "ndiswrap", get and unpack the "Intel PRO/Wireless Lan 2100" driver ("driver2" is what I used, and it works fine), read the "INSTALL" file from the "ndiswrap" tarball, follow the instructions. One thing that is a little unclear in their instructions, though: after you tell "install.sh" where the Intel files are, you can go ahead and delete them; they get copied (both the .inf and the .sys files) into "/lib/windrivers". So, when you need to test this thing and it wants to know where these files are, that's the directory you specify. In other words, the manual invocation goes like this:

modprobe ndiswrapper
loadndisdriver 8086 1043 /lib/windrivers/w70n51.sys /lib/windrivers/w70n51.inf
iwconfig wlan0 mode Managed
# *** Set this to your access point's ESSID, or "default" for a public access AP ***
iwconfig wlan0 essid <ESSID>

pump -i wlan0

After you've done this, you can play with it via "iwconfig wlan0 scan", etc. You can also look at "/proc/net/ndiswrapper/wlan0/{hw,stats,wep}" for various relevant info. For more hints, troubleshooting, etc., see the FAQ and the "tips" links at the "ndiswrap" site, above.

I'll be adding more information here when I finally do get a chance to get on the air.

Update, 03/29/04: Finally. I've just managed to drag the 'top over to my local airport, which happens to have an air port [that's a joke, son. You're supposed t' laugh, dammit.] - in fact, that's where I'm sitting now. The "loadndisdriver" line gives an error that sounds like a failure, but reading "dmesg" output tells me that the code just has some unimplemented routines, nothing to worry about. The main thing is that it responds with a MAC address, which means that the interface "exists" as far as Linux is concerned - and that's all we need it to do.

The speed, however, sucks. In Wind0ws, I'm getting an 11Mb/S connection - not that I've actually measured it, but Web pages snap onto the screen with a speed I've never experienced before. In Linux... [sigh] I'm doing a system update via "apt-get", and I'm running just about 28kB/S. I don't think it's the Debian server, either; I've tried surfing Google, and the results are dismal. Anyone that has info on speeding this up - having zero previous experience with wireless networks, I might be missing something trivial - please let me know. Not that I'm going to be here all that often, but I'd like to minimize the amount of buggy crap going on with this machine.

Update, 06/20/04: I've installed the ipw2100 driver from Intel; it works beautifully, high speed and everything. A little note for those who wish to follow in my footsteps: place the "hostap" directory inside the ipw2100 directory, compile "hostap", then compile ipw2100. Otherwise, you'll have to provide all sorts of ugly option to "make" - yeah, these are documented somewhere deep in the ipw2100 documentation, but why bother? Also, if you have a separate partition for "/usr" (as I do), placing Intel's firmware file in the default location, "/usr/lib/hotplug/firmware/", isn't going to work: the modules get loaded before the partitions get mounted. The fix is to place it in "/etc/firmware" and uncomment the CONFIG_IPW2100_LEGACY_FW_LOAD line in the ipw2100 makefile.

Don't forget: you're going to need to run "make" and "make install" in both of these directories every time that you recompile the kernel! (Hint: /lib/modules is a convenient place to put these directories. So is /usr/src.)

PCMCIA

Works just fine. Amazing, ain't it?

Here's me inserting a PCMCIA Ethernet adapter (ready? This is going to be really exciting...) 
ben@Fenrir:~$ tail -n 0 -f /var/log/messages
Feb 15 21:01:29 Fenrir kernel: Linux Tulip driver version 1.1.13 (May 11, 2002)
Feb 15 21:01:29 Fenrir kernel: PCI: Enabling device 0000:03:00.0 (0000 -> 0003)
Feb 15 21:01:29 Fenrir kernel: eth1: ADMtek Comet rev 17 at 0x4000, 00:10:7A:68:2F:74, IRQ 11.
Relevant kernel config:
Bus options (PCI, PCMCIA, EISA, MCA, ISA)  --->
			[*] PCI support
                            PCI access mode (Any)  --->
                        [*]   PCI device name database
                        [*] Support for hot-pluggable devices
                        PCMCIA/CardBus support  --->
                                       <*> PCMCIA/CardBus support
                                       <*>   CardBus yenta-compatible bridge support

For those who happen to have the same PCMCIA network card as I do - a NetGear CardBus FA511 - the relevant driver is not in the PCMCIA section of "Device drivers/Networking support" but in the "Ethernet (10 or 100Mbit)/Tulip family network device support" section in the same area. Odd but true, and one of the few "problems" here that is not Acer's fault. :)

Infrared

The biggest problem here was finding out what the heck the infrared hardware was: "findchip" from irda-tools was clueless; "lspci" didn't list anything; "dmesg" had no idea... oh yes - there is something Windows is good for! It's not actual hardware detection as such - more like, OEMs actually describe their hardware by name in the device manager. Before I remembered that, I managed to blow another hour or so trying to load the wrong IR driver (one that worked with another Acer laptop.) Once I got it, it only took a couple of seconds. Here are the settings in "Device Drivers/Networking support/IrDA (infrared) support":

<M> IrDA subsystem support
---   IrDA protocols
<M>   IrLAN protocol
<M>   IrNET protocol
<M>   IrCOMM protocol
[*]   Ultra (connectionless) protocol
---   IrDA options
[*]   Cache last LSAP
[*]   Fast RRs (low latency)
[*]   Debug information
      Infrared-port device drivers  --->
                --- SIR device drivers
                <M> IrTTY (uses Linux serial driver)
                <M> IrPORT (IrDA serial driver)
                --- FIR device drivers
                <M> SMSC IrCC (EXPERIMENTAL)

I've enabled all the different protocols for no better reason than I've never played with Linux IrDA yet, and want to have this stuff available. The important part is the last line, above: that's the driver for the IR hardware in this machine. Note: odd as it sounds, you'll need to enable "Bus options (PCI, PCMCIA, EISA, MCA, ISA)/ISA support" for that driver to even appear on the list. Ask not why, pilgrim; I know not, but I'm sure it's something dark and terrible...

Oh yeah - in order for the interface to be available, you need to bring it up. It's called "irda0", and the standard mechanism, at least in Debian, is to add it to "/etc/network/interfaces", like so: 
# /etc/network/interfaces -- configuration file for ifup(8), ifdown(8)

# The loopback interface
# automatically added when upgrading
auto lo eth0 irda0		# Add it here to bring it up right from the start
iface lo inet loopback

iface eth0 inet static
    address 192.168.1.30
    netmask 255.255.255.0

iface irda0 inet static         # Much like the Ethernet interface except for the IP
    address 192.168.1.35
    netmask 255.255.255.0
Now you can use "ifup" and "ifdown" on it. It will also come up automatically (assuming that you've got the "irda" and "smsc_ircc2" loaded) when you boot.

You'll want to install "irda-common", "irda-tools", and "irda-utils" (doesn't do you any good to have an interface if you don't have the tools to use it.) If you want to talk IrOBEX (e.g., connecting to your Palm Pilot via IR), you'll also need to install "openobex-apps". Now you'll be able to test the whole rig by running "irobex_palm3" and sending it, say, your business card or a random file from the Palm. At the bits'n'bytes level, you could fire up "irdadump" as root, and it'll tell you all about life in the infrared zone - in LOTS of detail. If you get in trouble, take a look at the "Infrared HOWTO", in many places on the Net.

Firewire

No idea. Haven't had a chance to test it, and it's a low probability that I ever will. The relevant modules load without any errors, though.

USB / USB2

USB works fine with the settings I have. In fact, it works much better than I expected: the 4-in-1 "Multimedia Card Reader" that comes with Acer is - again, thanks to Robos for the info - lives on the USB bus  and Just Worked when I tried it (although, in a very odd twist, it uses SCSI devices for its connection to the world.) I don't have all of the devices that it can handle to test it, but I've verified that it works well with the SmartMedia card from my Olympus D-40ZOOM camera and the SD card from my Palm Pilot. In the kernel config settings listed below, please note that I'm not saying that all of them are necessary, particularly the SCSI settings - but this kit of stuff works. I'll leave it to someone else to find the minimum necessary set. :) For those who are rarin' to go on that particular snipe hunt, here's what my "lsmod" looks like at the moment (the top three entries are relevant): 
ben@Fenrir:~$ lsmod
Module                  Size  Used by
usb_storage            63296  0 
sd_mod                 13792  0 
scsi_mod               71752  2 usb_storage,sd_mod
bsd_comp                5952  0 
snd_virmidi             3776  0 
snd_seq_virmidi         7136  1 snd_virmidi
fglrx                 208748  9
The kernel config looks like this:

Bus options (PCI, PCMCIA, EISA, MCA, ISA)
[*] Support for hot-pluggable devices
SCSI device support
<M> SCSI device support
<M>   SCSI disk support
<M>   SCSI CDROM support
[*]     Enable vendor-specific extensions (for SCSI CDROM)
<M>   SCSI generic support
[*]   Probe all LUNs on each SCSI device                       
[*]   Build with SCSI REPORT LUNS support
USB support
<*> Support for USB
[*]   USB device filesystem
<*>   EHCI HCD (USB 2.0) support
<*>   OHCI HCD support
<*>   UHCI HCD (most Intel and VIA) support
<*>   USB Modem (CDC ACM) support
<M>   USB Mass Storage support
[*]     USB Mass Storage verbose debug
[*]     SanDisk SDDR-09 (and other SmartMedia) support (EXPERIMENTAL)
[*]     SanDisk SDDR-55 SmartMedia support (EXPERIMENTAL)
As a result, this is what I get in "/var/log/messages" when I first plug in a SmartMedia card: 
Jan 30 14:47:11 Fenrir kernel: SCSI subsystem initialized
Jan 30 14:47:49 Fenrir kernel: hub 3-0:1.0: new USB device on port 1, assigned address 2
Jan 30 14:47:49 Fenrir kernel: Initializing USB Mass Storage driver...
Jan 30 14:47:49 Fenrir kernel: scsi0 : SCSI emulation for USB Mass Storage devices
Jan 30 14:47:49 Fenrir kernel:   Vendor:           Model: USB Card Reader   Rev: 1.2b
Jan 30 14:47:49 Fenrir kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jan 30 14:47:49 Fenrir scsi.agent[1596]: how to add device type= at /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host0/0:0:0:0 ??
Jan 30 14:47:49 Fenrir kernel: SCSI device sda: 256000 512-byte hdwr sectors (131 MB)
Jan 30 14:47:49 Fenrir kernel: sda: Write Protect is off
Jan 30 14:47:49 Fenrir kernel:  sda:<7>usb-storage: queuecommand called
Jan 30 14:47:49 Fenrir kernel:  sda1
Jan 30 14:47:49 Fenrir kernel: Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0
Jan 30 14:47:49 Fenrir scsi.agent[1621]: how to add device type= at /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host0/0:0:0:1 ??
Jan 30 14:47:49 Fenrir kernel:   Vendor:           Model: USB Card Reader   Rev: 1.2b
Jan 30 14:47:49 Fenrir kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jan 30 14:47:49 Fenrir kernel: Attached scsi removable disk sdb at scsi0, channel 0, id 0, lun 1
Jan 30 14:47:49 Fenrir scsi.agent[1641]: how to add device type= at /devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/host0/0:0:0:2 ??
Jan 30 14:47:49 Fenrir kernel:   Vendor:           Model: USB Card Reader   Rev: 1.2b
Jan 30 14:47:49 Fenrir kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Jan 30 14:47:50 Fenrir kernel: Attached scsi removable disk sdc at scsi0, channel 0, id 0, lun 2
Jan 30 14:47:50 Fenrir kernel: drivers/usb/core/usb.c: registered new driver usb-storage
Jan 30 14:47:50 Fenrir kernel: USB Mass Storage support registered.

DVD/CDRW

As recommended in the 2.6 kernel, I stopped using the SCSI emulation for CD writing; the IDE/ATAPI functionality seems to be up and working fine. The only difference was that I had to use the new ATAPI syntax with "cdrecord":

# Old device syntax
cdrecord -v dev=0,0,0 speed=24 file.iso

# New version
cdrecord -v dev=ATAPI:0,0,0 speed=24 file.iso

DVDs play just fine with "mplayer" and "ogle". Also, there's a firmware upgrade available for this drive at rpc1.org, but it seems to be completely up to date out of the box. I have not yet tried writing any DVDs, and will update this when I do.

Update, 2/24/04: Writing DVDs turns out to require a bit of setup. If you've never done it before, run do not walk to Joerg Schilling's site ProDVD and follow the instructions. The speed of this drive (Matshita/Panasonic UJ-815A) isn't too bad: it took 55.5 minutes to write a full 4.7GB DVD. Nice for backups. Do make a DVD-writing wrapper script as Joerg suggests; otherwise, your CD writing speed will be reduced to about 2x, probably not what you want.

Special keys

I have not yet had a chance to play with setting these up, although I suspect that "lineakd", which I was using with my Dell Inspiron, will do Good Things when I get around to it. Meanwhile, my biggest requirement in this regard - volume control - is being handled by the old mechanism I used before I ran into "lineakd", a Perl script that saves the current volume settings via "cam" and adjusts them based on how it's invoked: 

#!/usr/bin/perl -w
# Created by Ben Okopnik on Sat Jun  1 01:00:39 EDT 2002

die "Usage: ", $0 =~ /([^\/]+)$/, " -u|-d\n" unless $ARGV[0] =~ /^-[ud]$/;

# Save current volume level, which may be different from the .camrc...
system qw/cam -save/ and die "Weirdness has occured: save failed. $!\n";

open RC, "$ENV{HOME}/.camrc" or die "Couldn't open ~/.camrc: $!\n";

# Read only the second line (volume)
while ( <RC> ){ ( $vol ) = /(\d+)/ if $. == 2; }

$ARGV[0] =~ /u/ ? ( $vol > 95 ) || ( $vol += 5 ): ( $vol < 25 ) || ( $vol -= 5 );
system "cam -v $vol,$vol -p $vol,$vol -S $vol,$vol -c $vol,$vol";
I then tied this script to a couple of hotkeys, like so: 
ben@Fenrir:~$ grep vol .icewm/keys
key "Alt+Ctrl+a" voladj -u
key "Alt+Ctrl+z" voladj -d
Update, 4/10/04: Got a nice hint from the whatlaptop forum on this. If you look inside the Arcade tarball, there's a file called "enableub" in the "/cplay" directory; oddly enough, it enables user bindings. :) Also, get a hold of "/etc/rc2.d/S92keymap" - it actually maps the keys to reasonable keycodes (which you can then set up to trigger whatever action you like.) I've tried it, and it works - but I haven't actually implemented it, since I've never been much of a fan of "extra keys" anyway. Here is the list of all the keys that "wake up" as a result (you can see it happening in "xev", etc.):
Subwoofer On/Subwoofer Off	# These already work by default

Arcade

Power-off			# Could be useful in later ACPI setup

FN+F1				# Hmm... map it to "tkman", perhaps? :)
FN+F3				# More ACPI bait
FN+F5
FN+F8
FN+Up
FN+Down

5-way + stop key		# This would actually be pretty nice when mapped to, say, "xmms" or "mplayer"!
	Up
	down
	enter
	right
	left

Kernel configuration

In the process of trying to get this thing working, I've gone from the 2.4.22 kernel, through a couple of 2.6.0-testXX kernels, and am now working with 2.6.3. The resulting changes have been small but positive, and have affected (if I recall correctly) the Synaptics touchpad, the Ethernet hardware, and ACPI (although sleep and suspend are still broken - the one major remaining problem with this laptop), all the ACPI-related devices are now visible and their status can be read from "/proc/acpi". I can only hope that the future brings better things - although having to deal with the proprietary ATI X server is a big stumbling block on that road.

Update, 6/3/04: I'm now  running the 2.6.5 kernel and about to upgrade to 2.6.6.  There have been a few small improvements, but ACPI still isn't fully workable - no suspend or sleep, although all the battery, etc. state reporting is good.

For those who are interested, here is my 2.6.5 kernel config.

Update, 6/20/04: I'm up to 2.6.7-rc3 at this point. It's still highly experimental, but it allows me to have my "hibernate" facility and my "ati" driver. No major complaints so far, although it appears to have an occasional problem with the ppp driver.

And here is the latest kernel config, 2.6.7-rc3.

Credits to...

Me! :) I never knew I had this much patience... in fact, this document's working title was "How I didn't throw an Acer Aspire 2003LMi into the trash, and why I should be adored, worshipped, and rewarded for my angelic patience (an inquiry into values, behavior, technology, and philosophy)." Alas, the day when Chinese poets gave their poems names that were longer than the composition itself are sadly past, so I had to settle for the short version. (However, everyone should still worship me. I mean, it's not like I'm asking for anything unreasonable; that comes later.)

The Answer Gang, especially Robos for his perseverance!

ATI (albeit grudgingly and with mixed feelings due to the semi-closed source stuff) - for putting out a long and exhaustive README. It wasn't actually of much help directly, but it started me on some good lines of inquiry that sometimes terminated in an answer.

amanous at softlab.ntua.gr, from whom I stole the format of this page (he did something very similar for his Dell Inspiron laptop, and I liked it so much that I ran off with it.)

All the good Linux folks on the Net who document their efforts and answer the questions of those in need.

Google! The search engine sans peur et sans reproche, these folks are the sine qua non (what the hell is it with me and furrin languages today?) of Net research. Without them, this would have been impossible.

* Ben Okopnik * okopnik.freeshell.org * Editor-in-Chief, Linux Gazette *
-*- See the Linux Gazette in its new home: <http://linuxgazette.net> -*-