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

For those of you who don’t believe in README’s:

Option "OnDemandVBlankInterrupts" "true"

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.

1300 people, three hours sleep and games at any hour of the day (plus the occasional freebies – mostly lots of bottle openers, a pen and a t-shirt and an inflatable thing from Samsung to hit people with, so far) – what more could you want in life?

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