I’ve been rather quiet lately, so time for the latest news:

1) The input part of acer_acpi (the keyboard quirks) has been accepted by Dmitry Torokhov (the input subsystem maintainer) into his tree. This will be going into 2.6.25 – this means that if you have one of the laptops that requires the old acerhk keyboard quirk to make the extra scancodes work, you won’t need acer_acpi just for this fro 2.6.25 onwards. (This code is not acer_acpi specific, so I’ve never been happy with it just sitting in acer_acpi).

2) No news on any other upstream front I’m afraid – wmi & acer-wmi (the upstream port of acer_acpi) are _still_ waiting to be reviewed by the ACPI maintainer (not that I’m getting a little irritated now after three months…)

3) acer_acpi 0.11 will hopefully be released soon – I’ve not had any word of the device autodetection code breaking horribly. Quite the contrary, reports so far indicate that it’s working quite well, so it’s almost time to inflict^^^^^^release it.

4) There appears to be a bug with OpenSuSE 10.3 and the wmi-acer/ wmi module –

https://bugzilla.novell.com/show_bug.cgi?id=352648

I’m aware of it – but currently have no clue as to why it doesn’t work on OpenSuSE, yet works on the same hardware with other distributions.

After re-reading an old readme & history file bundled with a different release of Launch manager (the one available for the Aspire 1690 – same version as the 5020 version, but this EXL806WW.BLD.txt file is missing from the 5020 release), I finally figured out that:

1) It is actually possible to auto detect hardware on older Acer laptops
2) That I had originally misread this file, and that this can be done via ACPI-WMI

So, after ordering myself a firewire (aka ieee1394) cable, I’ve been able to play about with remote kernel debugging in Windows (unfortunately, forcing ACPI into step-by-step mode isn’t useful on a single machine, as it completely locks the machine and you need a remote one to force Windows to go to the next step. And the Windows kernel debugger can only do a remote connection via serial or firewire).

The result is that:

1) I can detect bluetooth on my Aspire 5020
2) I can take a good guess at how wireless detection works
3) I’m not sure on the Mail LED detection, but I do have some ideas.

Hopefully, this should be portable to the other older AMW0 type 1 laptops (and, fingers crossed, the non Acer laptops that also fall into this category). (In theory, based on Wistron’s comments in the driver, this method may well be portable to acerhk and wistron-btns, in the sense that the WMI interface on these laptops is just a front end for the old BIOS calls).

WMI: Latest version (v7) was published on the ACPI mailing lists (I finally figured out my problems). This work has been ported to acer_acpi already (and not a moment too soon, since the Aspire 7520 has multiple PNP0C14 devices).

acer-wmi: Initial RFC (request for comment aka first try, please review) has been posted to the ACPI mailing list. For WMID users, they will see no change. For AMW0 v1 users, the Aspire 5020 EC quirks are enabled by default (since all such laptops reported so far have the same quirk). The biggest change for is AMW0 v2 users, who have been switched over to the WMID methods.

I can’t do this in acer_acpi as I suspect, based on earlier reports, that there may be some upstream ACPI bugs we need to flush out to get this working properly, and I can’t backport ACPI bugfixes into acer_acpi.

I’ve been poking around the ‘newer’ AMW0 DSDT implementation (I’ll call it AMW0 v2), and I think I’ve worked it out now. Basically, rather than being an extension of the old AMW0 (we’ll name this ‘AMW0 v1′ to be original), it’s actually a backwards compatible addition of WMID to AMW0 – it has all the methods from both (plus an extra method to return a binary MOF), so can be treated as either.

So, for background – acerhk worked by making 32 bit BIOS calls. These calls take four arguments, each 4 bytes long, to give a total of 16 bytes.

AMW0 v1 just shifts the call into a method in WMI ACPI – we use the same arguments, but the call is done in ACPI, so we don’t have to care about poking into the BIOS, or whether this is a 32 or 64 bit system.

WMID implemented a ’simple’ method, so rather than needing to know the exact arguments for the BIOS, we just give the relevant method ID (and for writing, also the value), and then call that.

AMW0 v2 implements all the old AMW0 v1 methods, so is completely backwards compatible. However, since it also implements all of the WMID interface, it should be possible to update acer_acpi to use the WMID methods instead on these laptops, since it means we don’t need EC data for reading wireless and bluetooth (with the added advantage that we can control the mail LED through the ‘old’ AMW0 v1 methods).

Since some people apparently read this blog (for some unfathomable reason…), some more updates on progress in WMI-ACPI land.

Background:

I am currently trying to implement a mapping driver in Linux for WMI-ACPI (which is described here)

The short, short version for doing this is that unlike other laptop manufacturers, who define their own custom devices in ACPI-land and then talk to those directly, Acer uses WMI-ACPI, which is a proprietary standard defined by Microsoft. Unfortunately, Acer are not the only ones who use WMI-ACPI, so we cannot just assume that a WMI-ACPI device (PNP0C14 in ACPI & DSDT talk) is for Acer hardware and try to unilaterally claim it. Therefore, a generic driver needs to be written to handle WMI-ACPI (PNP0C14), and then acer_acpi can be rebuilt on top of this generic driver, instead of trying to talk directly to ACPI.

Current Progress:

So, to get to what you’re really interested in:

1) I did have a working WMI mapper (a lot of my early work can be found in the latest acer_acpi 0.10 RC releases).

2) However, the first round of comments pointed out that the WMI-ACPI specification calls for a full kernelspace to userspace mapper – so while I am not expected to (and probably won’t) write the userspace component, I did need to add another interface to the kernel part of the WMI-ACPI mapper to expose it to userspace (in this case, sysfs was recommended).

3) So I added a sysfs interface to expose WMI-ACPI to userspace. However, after releasing the latest versions with this (5, and 6 which just split WMI into two smaller, easier to review patches), I realised there were quite a few bugs & implicit assumptions in wmi.c:

i) wmi.c assumed there would only ever be one PNP0C14 device – according to the MS spec, this is not so – there can be many.

ii) wmi.c assumed a WMI method would always take input, and would execute a method then. Again, this is not true – rechecking the MOF’s I have for WMID Acer laptops, it’s clear that not all functions take an input.

iii) I also spotted a few cases of where I was needlessly re-inventing the wheel (as has been pointed out to other people in the past, and I keep learning – when you want to do something, there’s probably already a function in the kernel that does it).

So, although I have fixed most of these problems locally, I’ve broken the sysfs interface for the mapper with the changes required for (ii), and haven’t figured out how to fix it yet (hence the delay in publishing version 7 on the Linux ACPI mailing list). (And no, I don’t have a Git tree available with my changes – when the patches are ready for review, I’ll publish them to the mailing list. And quite frankly, at the moment they’re a mess again and need cleaning up regardless).

So, the promised update on getting acer_acpi upstream.

1) The generic WMI-to-ACPI mapping driver to go upstream will now be written by me.

My current work on this driver has already been integrated into the 0.10 RC releases – I will continue to backport my WMI work to acer_acpi (where possible and practical) until it gets accepted upstream.

2) The ‘upstream’ acer_acpi will likely be renamed acer-wmi, so as to:

i) Make it clear that acer_acpi is the out of tree version, and avoid any confusion with the in tree (acer-wmi) driver – as once acer-wmi is accepted upstream, development work will cease on the out-of-tree acer_acpi – I will maintain and bugfix it only for older kernels. The recommended path will be to upgrade to the latest stable kernel with acer-wmi (or nag your distribution to update their kernel).

iii) acer-wmi will now call the WMI driver (acer_acpi will call its own internal copy)

iv) The use of the -acpi name is being deprecated by the “next generation” of laptop drivers (sony-laptop, asus-laptop). Whilst I have considered the “acer-laptop” name, I feel it is inappropriate, since we are only driving the WMI based laptops, not all Acer laptops.

The acer_acpi name is also inappropriate, because as of 0.10 RC, acer_acpi is not really an ACPI driver anymore – it has bits of ACPI in it, but WMI is the “true” ACPI driver, whilst acer_acpi is now a platform driver[1] that just calls into WMI to do the ACPI bits for it.

(WMI has a defined ACPI interface device (PNP0C14) by Microsoft, so acer_acpi cannot claim the WMI-ACPI device for itself. Otherwise, if someone else wanted to write another Linux driver against WMI-ACPI, it would be a race between this driver and the other ones to claim PNP0C14. So instead, we will have just one WMI driver, which claims PNP0C14, and then other drivers just call into WMI to access the WMI-ACPI functionality.

(This is in contrast to other laptop vendors, who just define their own out-of-spec devices, so Linux drivers for them can claim these ACPI devices and drive them, since nothing else will).

3) The following from acer_acpi will _not_ be present in acer-wmi:

i) proc interface – PITA to maintain, and upstream will not accept new /proc interfaces for ACPI. The sysfs interface + subsystem integration is the future.

ii) Extra keys toggling – As per my discussions with the input subsystem maintainer, this belongs in i8042.c, not acer-wmi.

iii) Fan override – I’m not entirely comfortable submitting this straight away. I’d prefer to get acer-wmi in, then consider re-adding this later.

[1] A ‘platform’ driver, in the Linux kernel, to quote from Documentation/driver-model/platform.txt:

“This pseudo-bus is used to connect devices on busses with minimal infrastructure [..]; as opposed to large formally specified ones like PCI or USB.”

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).

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.

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