A few people have asked me, on occasion, when acer_acpi will go upstream - the answer is eventually

Basically, two things must happen first:

1) A generic WMI driver must be added upstream - this is being worked on by the Linux ACPI developers (hopefully, with more news to come after this weeks Linux developers conference)

2) acer_acpi would be rebased against this new WMI driver (possibly renamed to ‘acer-wmi’ or similar, to differentiate it from acer_acpi). This new driver would also completely drop /proc support (which is a PITA to maintain anyway).

Long term:

acer_acpi would be maintained, but not actively developed, for older kernels (i.e bug fixes only)

acer-wmi (or whatever the ‘new’ WMI based driver is called) would be the actively developed driver.

There are better ways to spend a Saturday afternoon than ripping out a /proc interface, replacing it with sysfs, and then getting carried away by making your driver integrate, where possible, into the various kernel subsystems.

In lieu of this, a few days ago I ripped out the last vestiges of “hotkey” support - it isn’t required on modern Acer laptops (either the keys work out-of-the-box, or they generate the relevant scan codes and can be easily mapped to keycodes).

To summarise today’s efforts:

1) Ripped out all remaining vestiges of /proc (it’s full of nearly impossible to read code, copied from other drivers, who in turn had little idea what the interface code did. proc is a case of square peg, round hole).

2) Converted acer_acpi to create a new platform driver (i.e. a driver that doesn’t really fit anywhere else) called “acer-laptop” and assign wireless, bluetooth and the experimental 3G to this platform driver (if you assign the properties to ACPI, then end up buried deep in the bowels of sys)

The mail LED is moved to the LED subsystem as acer:mail (in accordance with how asus-laptop implements their mail LED).

Brightness (WMID only) is moved to the backlight subsystem - it looks like it might even work (it doesn’t crash hideously, or segfault, at least), but I don’t have the hardware, so it’s otherwise completely untested.

3) Discovered that as far as Linux’s ACPI implementation is concerned, pnp0c14 != PNP0C14. This minor little detail meant that on my machine, using the older AMW0 interface, the acpi_driver didn’t run its attached operation functions (e.g. add, remove and resume, which in turn call other functions that are required to set up all functionality)

I may even get round to submitting this upstream one day (although I’m certain there’s more clean up work/ refactoring that can be done first with the removal of proc).

For anyone who’s interested, the latest version oh pkgcmp.sh can always be found here: http://files.strangeworlds.co.uk/pkgcmp.sh

pkgcmp.sh is a shell script that compares PACKAGES.TXT from Slamd64 and Slackware, and reports all the differences in package versions, and missing/ added packages between the two (it doesn’t compare BUILD though, as there is no meaningful way to do so).

More from acer_acpi land; thanks to a nudge in the right direction, I’ve been poking around Launch Manager using ’strings’, looking for any and all of interest that might come up. As some may have noticed, acer_acpi isn’t intelligent about detecting hardware (i.e. we don’t) - hence on my system, I get a /proc/acpi/acer/bluetooth, even though my laptop (Aspire 5021) doesn’t have it (Of course, we can’t decide based on the model number - the BIOS only tells us the series, 5020 in this case, and there are other laptops in that series that do have bluetooth).

So how does Launch Manager do it? Some hidden, special, undocumented feature? Nope - it just has a list of PCI ID’s. Not really a lot of use, since in the case of wireless, you could change the mini PCI card, and then what - acer_acpi won’t turn on the wireless because it “isn’t supported”? (Of course, I have no idea if Acer’s BIOS limits which wireless cards can and can’t be connected - we’ll have to assume, unless otherwise disproven, that there is no limit). Can’t go by poking at a PCI slot, since acer_acpi runs on lots of different hardware. So wireless detection is out. (We could potentially get a false positive, but I’ve yet to see any system that uses acer_acpi that lacks wireless).

Bluetooth? Bluetooth is just an internal USB dongle - so we _could_ go by the manufacturer and device ID… unless you happen to have an external USB device that matches - false positive, we show a bluetooth option when we shouldn’t.

1) Install UT2004 from DVD/ CDs
2) Install megapatch from liflg.org
3) Re-install 3369 patch (because megapatch buggers things up)
4) AMD64 only (e.g. Slamd64): In System, rename *-linux-amd64 to overwrite the 32 bit binaries (e.g. drop the -linux-amd64)
5) Enjoy

acer_acpi 0.5 has been released today (with yours truly as the new maintainer - yes, the world really has come to this). Enjoy!