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