The DSDT (Differentiated System Description Table) is a part of the ACPI (Advanced Configuration and Power Interface) specification, which supplies configuration information about a base system. ACPI capable computers come with a preinstalled DSDT from the manufacturer stored in BIOS. This is a piece of code in a special language, AML, which is evaluated by the OS with an in-kernel interpreter.

It implements functionality such as turning off the screen when the laptop lid is closed, changing the screen brightness when the Fn-key combinations are used, and enabling/disabling hardware such as the Wifi transmitter for power saving.

Slight differences in the interpretation between Linux and Windows of the DSDT can cause problems such as, in my case, the wireless kill switch and Bluetooth somehow doesn't work. The other fn-X keys do work...

To troubleshoot issues, the code can be compiled and decompiled by the AML compiler, iasl.

The problem is that it appears to be hardly documented. The language itself is explained in the ACPI specification, but obviously that excludes the platform specifics which are the interesting part.

To make matters worse, a special 'device' is implemented by DSDT, called WMID (Windows Management Instrumentation Device), that offers services (such as switching devices on and off for power saving) to Windows. The course interface is documented, but the platform specifics are, again, not.

The interesting device driven from DSDT 'code' is EC0, the Embedded Controller, a microprocessor that controls power management and other internal hardware. This is the part that is different between mainboards and laptop types.

Example code looks like this:

    Store (^^LPC.EC0.WLEX, AS00)
    Sleep (0x1E)
    Store (^^LPC.EC0.BTEX, AS01)
    Sleep (0x1E)
    Store (Zero, AS02)
    Store (^^LPC.EC0.W3GE, AS04)
    Sleep (0x1E)
    Store (^^LPC.EC0.MPEX, AS05)

Here the guessing begins. What are the four letter abbreviations? WLEX=Wireless? BTEX=Bluetooth? W3GE=3G (not supported on mine), and MPEX?

    CreateField (AADS, Zero, 0x04, AS00) /* 0x0000000F */
    CreateField (AADS, 0x04, One, AS01)  /* 0x00000010 */
    CreateField (AADS, 0x05, One, AS02)  /* 0x00000020 */
    CreateField (AADS, 0x06, One, AS04)  /* 0x00000040 */
    CreateField (AADS, 0x08, One, AS05)  /* 0x00000100 */
    CreateField (AADS, 0x10, 0x10, AS03) /* 0xFFFF0000 */

AADS is an interface to capabilities and status, a 32 bit buffer with flags. Control of the EC0 (Embedded Controller):


It looks like these are switched through WMID (Windows). This explains why the internal ACPI handling will not switch them.

Switched via the method WSDS(a,b) on Device WMID, WSDS(a,b) (setter), WGDS(a) (getter). The setter is called via WMBA(a,b,c). WMBA is never called internally, but is an external interface to getters/setters.

The utility wmidump can be used to dump the mapping between GUIDs and DSDT Method names:

GUID Method In driver Type
6AF4F258-B401-42FD-BE91-3D4AC2D7C0D3 (WM)BA WMID_GUID1 Method
95764E09-FB56-4E83-B31A-37761F60994A (WQ)AA WMID_GUID2 Query block

These are the WMID_GUID1 and WMID_GUID2 as used in the acer-wmi driver. Then what is wrong, why doesn't the driver load? Probably, the interface changed a bit without changing the UUID.

Checked using wmiiexec: WQAA returns 8 bytes now. It returns BUFF and the definition of BUFF is Name (BUFF, Buffer (0x08). The driver checks the size to be 4, which of course fails. Looking at the code, the only output that is ever put into WMID_GUID2 is:

EC0 bit Mem Bitmask (returned buffer)
LPC.EC0.WLEX AS00 0x0000000F
LPC.EC0.BTEX AS01 0x00000010
LPC.EC0.W3GE AS04 0x00000040
LPC.EC0.MPEX AS05 0x00000100
Now that we deducted the bits to detect Wireless and 3G, we could add this to the driver. The next step is to see if we can trigger something on the 'kill switches' (a WMI event?), and finding out what the other bits do. I just found A list of WMID UUIDs for ACER, where does the MOF file come from? Some more background here.
Written on May 18, 2010