Looking for some pointers on WMI/EC access

Hello everyone,

I've just bought an Ideapad S10-3t, and most features including ACPI work fine. However, since neither thinkpad-acpi nor lenovo-sl-laptop support this device, I've been looking around for some hints on how to access the embedded controller in order to get the hotkeys working. I'll post what I've found so far and hope that somebody could give me some hints as to how to proceed.

First, I've dumped the DSDT and browsed through it. I've found a _WDT section, and wmidump shows:

ABBC0F20-8EA1-11D1-00A0-C90629100000:
       object_id: �
       notify_id: 80
       reserved: 00
       instance_count: 1
       flags: 0x8 ACPI_WMI_EVENT
ABBC0F40-8EA1-11D1-00A0-C90629100000:
       object_id: IO
       notify_id: 49
       reserved: 4F
       instance_count: 1
       flags: 0x1 ACPI_WMI_EXPENSIVE
05901221-D566-11D1-B2F0-00A0C9062910:
       object_id: AE
       notify_id: 41
       reserved: 45
       instance_count: 1
       flags: 0

As this laptop also runs some kind of Splashtop instant-on Linux called Lenovo Quickstart, I've decided to extract the initrd from its kernel (*) and browse through the modules. Interestingly, I've found a lenovo_ec.ko: strings shows that it accesses some DSDT elements which are present on the S10-3t. Would it make sense to disassemble this?

Quoted 8 lines

I've just bought an Ideapad S10-3t, and most features including ACPI work fine. However, since neither thinkpad-acpi nor lenovo-sl-laptop support this device, I've been looking around for some hints on how to access the embedded controller in order to get the hotkeys working. I'll post what I've found so far and hope that somebody could give me some hints as to how to proceed.
First, I've dumped the DSDT and browsed through it. I've found a _WDT section, and wmidump shows:

Wow, someone actually used that tool ^^
A Quick hint would be to look at
https://patchwork.kernel.org/patch/87210/ which is basically a really short example of what a wmi-driver is.
Just change the guid, buid/load, push some hotkeys, see dmesg, edit the keymap, build, load, test ..

Quoted 10 lines

ABBC0F20-8EA1-11D1-00A0-C90629100000:

       object_id: �
       notify_id: 80
       reserved: 00
       instance_count: 1
       flags: 0x8 ACPI_WMI_EVENT
ABBC0F40-8EA1-11D1-00A0-C90629100000:
       object_id: IO
       notify_id: 49
       reserved: 4F

Quoted 8 lines

       instance_count: 1
       flags: 0x1 ACPI_WMI_EXPENSIVE
05901221-D566-11D1-B2F0-00A0C9062910:
       object_id: AE
       notify_id: 41
       reserved: 45
       instance_count: 1
       flags: 0

Quoted 5 lines

As this laptop also runs some kind of Splashtop instant-on Linux called Lenovo Quickstart, I've decided to extract the initrd from its kernel (*) and browse through the modules. Interestingly, I've found a lenovo_ec.ko: strings shows that it accesses some DSDT elements which are present on the S10-3t. Would it make sense to disassemble this?

You can also try to see if the manufacturer give some sources or ask them to ...

Am Sonntag, den 18.04.2010, 21:21 +0200 schrieb Corentin Chary:

Quoted 9 lines · Florian Echtler

Quoted 8 lines

I've just bought an Ideapad S10-3t, and most features including ACPI work fine. However, since neither thinkpad-acpi nor lenovo-sl-laptop support this device, I've been looking around for some hints on how to access the embedded controller in order to get the hotkeys working. I'll post what I've found so far and hope that somebody could give me some hints as to how to proceed.
First, I've dumped the DSDT and browsed through it. I've found a _WDT section, and wmidump shows:

Quoted 6 lines

Wow, someone actually used that tool ^^
A Quick hint would be to look at
https://patchwork.kernel.org/patch/87210/ which is basically a really short example of what a wmi-driver is.
Just change the guid, buid/load, push some hotkeys, see dmesg, edit the keymap, build, load, test ..

Thanks for the pointer - I've given it a quick try and the driver loads successfully, however, the event doesn't seem to be triggered. I've put a printk into the eeepc_wmi_notify function, and this is seemingly never called.. although I believe this may be the right direction, as the GUID from the eeepc driver (ABBC0F72-8EA1-11D1-00A0-C90629100000) and the one from my Lenovo (ABBC0F20-8EA1-11D1-00A0-C90629100000) differ only by a single byte.

Could this event be disabled somehow?

Corresponding to the 2nd GUID, there's also a WQIO method in my DSDT which should return a data block, correct?

Hello Corentin,

Quoted 15 lines

Quoted 15 lines

Quoted 8 lines

Quoted 2 lines

First, I've dumped the DSDT and browsed through it. I've found a _WDT section, and wmidump shows:

Wow, someone actually used that tool ^^
A Quick hint would be to look at
https://patchwork.kernel.org/patch/87210/ which is basically a really short example of what a wmi-driver is.
Just change the guid, buid/load, push some hotkeys, see dmesg, edit the keymap, build, load, test ..

Thanks for the pointer - I've given it a quick try and the driver loads successfully, however, the event doesn't seem to be triggered. I've put a printk into the eeepc_wmi_notify function, and this is seemingly never called.. although I believe this may be the right direction, as the GUID from the eeepc driver (ABBC0F72-8EA1-11D1-00A0-C90629100000) and the one from my Lenovo (ABBC0F20-8EA1-11D1-00A0-C90629100000) differ only by a single byte.

Quoted 4 lines

This is not the first laptop with an asus-like dsdt, some Lenovo are supported by asus-laptop.

Quoted 1 line

Could this event be disabled somehow?

Don't know, can you send the result of acpidump ?

I've attached the output of acpidump as well as the decompiled DSDT.

Quoted 17 lines · Florian Echtler

Hello Corentin,

Quoted 15 lines

Quoted 15 lines

Quoted 8 lines

Quoted 2 lines

First, I've dumped the DSDT and browsed through it. I've found a _WDT section, and wmidump shows:

Wow, someone actually used that tool ^^
A Quick hint would be to look at
https://patchwork.kernel.org/patch/87210/ which is basically a really short example of what a wmi-driver is.
Just change the guid, buid/load, push some hotkeys, see dmesg, edit the keymap, build, load, test ..

Thanks for the pointer - I've given it a quick try and the driver loads successfully, however, the event doesn't seem to be triggered. I've put a printk into the eeepc_wmi_notify function, and this is seemingly never called.. although I believe this may be the right direction, as the GUID from the eeepc driver (ABBC0F72-8EA1-11D1-00A0-C90629100000) and the one from my Lenovo (ABBC0F20-8EA1-11D1-00A0-C90629100000) differ only by a single byte.

Quoted 5 lines

Quoted 4 lines

This is not the first laptop with an asus-like dsdt, some Lenovo are supported by asus-laptop.

Quoted 1 line

Could this event be disabled somehow?

Don't know, can you send the result of acpidump ?

I've attached the output of acpidump as well as the decompiled DSDT.

Looking at your dsdt:

BUF1 and BUF2 contains some easy to find data:

                       CreateByteField (BUF1, 0x01, EID1) CreateByteField (BUF1, 0x02, ERQ0) CreateByteField (BUF1, 0x03, BRIL) CreateByteField (BUF1, 0x04, SKEY) CreateByteField (BUF1, 0x08, BLUE)  bluetooth CreateByteField (BUF1, 0x09, WLAN) wifi CreateByteField (BUF1, 0x0A, WL3G) 3g CreateByteField (BUF1, 0x0B, WMAX) wimax CreateByteField (BUF1, 0x0C, GLSW) CreateByteField (BUF1, 0x10, TPST) touchpad ? CreateByteField (BUF1, 0x11, SLMD) CreateByteField (BUF1, 0x12, SBR0) brightness ? CreateByteField (BUF1, 0x13, SBR1) CreateByteField (BUF1, 0x14, SBR2) CreateByteField (BUF1, 0x15, SBBR) CreateByteField (BUF1, 0x16, SBLI) CreateByteField (BUF1, 0x17, TBMD) CreateByteField (BUF1, 0x18, RTAG)

                       CreateByteField (BUF2, 0x01, EID2) CreateByteField (BUF2, 0x08, BIV0) CreateByteField (BUF2, 0x09, BIV1) CreateByteField (BUF2, 0x0A, BIV2) CreateByteField (BUF2, 0x0B, BIV3) CreateByteField (BUF2, 0x0C, BIV4) CreateByteField (BUF2, 0x0D, BIV5) CreateByteField (BUF2, 0x0E, BIV6) CreateByteField (BUF2, 0x0F, BIV7) CreateByteField (BUF2, 0x10, WMIV) CreateByteField (BUF2, 0x18, BRMX) brightness max ? CreateByteField (BUF2, 0x20, BAT1) battery CreateByteField (BUF2, 0x21, BAT2) battery CreateByteField (BUF2, 0x22, ACDC) music ? :p CreateByteField (BUF2, 0x23, CPUT) cpu temp ? CreateByteField (BUF2, 0x24, VGAT) CreateByteField (BUF2, 0x25, CDT1) CreateByteField (BUF2, 0x26, CDT2) CreateByteField (BUF2, 0x27, FSP1) CreateByteField (BUF2, 0x28, FSP2)

Looking at _INI :
      Store (\_SB.BRNS, BRMX) probably means "set the brightness to the maximum brightness"

WQIO returns both BUF1 and BUF2, you can get it with wmi_query_block()

WSIO calls CPSR and CPSR store the argument in INBF. BY00, BY01, ... BY31, BGTX, BGTY, BGTZ etc ... are used to access specific bytes in INBF :
                       CreateByteField (INBF, 0x00, BY00) CreateByteField (INBF, 0x01, BY01) CreateByteField (INBF, 0x02, BY02) CreateByteField (INBF, 0x03, BY03) CreateByteField (INBF, 0x04, BY04) CreateByteField (INBF, 0x05, BY05)

CSPR wants BY00 to be 0x01 and BY01 to be 0x10 to do something. It calls CMD0 (BY08, BY09, BY10, BY11, BY16)

ERQ0 (present in BUF1) is compared to Arg2 (BY09) == 0x1 if true, it will store some values and call notify

Quoted 3 lines

Looking at your dsdt:

BUF1 and BUF2 contains some easy to find data:

Quoted 17 lines

Looking at _INI :
Store (\_SB.BRNS, BRMX) probably means "set the brightness to
the maximum brightness"

WQIO returns both BUF1 and BUF2, you can get it with wmi_query_block()

WSIO calls CPSR and CPSR store the argument in INBF. BY00, BY01, ... BY31, BGTX, BGTY, BGTZ etc ... are used to access specific bytes in INBF :

                       CreateByteField (INBF, 0x00, BY00)
                       CreateByteField (INBF, 0x01, BY01)
                       CreateByteField (INBF, 0x02, BY02)
                       CreateByteField (INBF, 0x03, BY03)
                       CreateByteField (INBF, 0x04, BY04)
                       CreateByteField (INBF, 0x05, BY05)

Quoted 5 lines

CSPR wants BY00 to be 0x01 and BY01 to be 0x10 to do something. It calls CMD0 (BY08, BY09, BY10, BY11, BY16)

ERQ0 (present in BUF1) is compared to Arg2 (BY09) == 0x1 if true, it will store some values and call notify

Method (GECN, 1, NotSerialized)
Method (SECN, 2, Serialized)

are very interesting:

GECN is used to get status, and SECN to set status.

For example, use \_SB.GECN(0x03) to get bluetooth status And \_SB.SECN(0x03, 0x01) to enable bluetooth.
I don't really understand what DECN is used for, maybe to know if a device is present (or maybe just switch GECN and DECN).

Hello Corentin,

Quoted 3 lines

Quoted 3 lines

Looking at your dsdt:

BUF1 and BUF2 contains some easy to find data:

[...]
You're correct, but most of the data fields within BUF1 and BUF2 are never referenced anywhere else. Doesn't that mean that these fields are probably dead?

Quoted 17 lines

Quoted 17 lines

Looking at _INI :
      Store (\_SB.BRNS, BRMX) probably means "set the brightness to the maximum brightness"

WQIO returns both BUF1 and BUF2, you can get it with wmi_query_block()

WSIO calls CPSR and CPSR store the argument in INBF. BY00, BY01, ... BY31, BGTX, BGTY, BGTZ etc ... are used to access specific bytes in INBF :
                       CreateByteField (INBF, 0x00, BY00) CreateByteField (INBF, 0x01, BY01) CreateByteField (INBF, 0x02, BY02) CreateByteField (INBF, 0x03, BY03) CreateByteField (INBF, 0x04, BY04) CreateByteField (INBF, 0x05, BY05)

Quoted 5 lines

Quoted 5 lines

CSPR wants BY00 to be 0x01 and BY01 to be 0x10 to do something. It calls CMD0 (BY08, BY09, BY10, BY11, BY16)

ERQ0 (present in BUF1) is compared to Arg2 (BY09) == 0x1 if true, it will store some values and call notify

So this would then trigger the WMI event in the driver, right? I'd assume that EVID is the EVent ID - would make sense, since somewhere in the embedded controller code, there's this snippet:

       Method (_QEF, 0, NotSerialized)
       {
               Store (0xEF, P80H)
               \_SB.WMI2.CMD2 (0x2D, 0x01, 0x01)
       }

       Method (_QF1, 0, NotSerialized)
       {
               Store (0xF1, P80H)
               \_SB.WMI2.CMD2 (0x2C, 0x01, 0x01)
       }

AFAICT the problem might be that ERQ0 is never initialized.. so it's probably zero from the start and the first code branch in CMD0 will never be called.

Quoted 11 lines

Method (GECN, 1, NotSerialized)
Method (SECN, 2, Serialized)

are very interesting:

GECN is used to get status, and SECN to set status.

For example, use \_SB.GECN(0x03) to get bluetooth status And \_SB.SECN(0x03, 0x01) to enable bluetooth.
I don't really understand what DECN is used for, maybe to know if a device is present (or maybe just switch GECN and DECN).

I've gone through the binary module from Splashtop (lenovo_ec.ko) with objdump, and it appears that it's calling exactly those methods (GECN,SECN,DECN). The EC registers themselves also do look very interesting, especially with fields like XALM/YALM/ZALM or GSVX/GSVY/GSVZ which are probably related to the accelerometer.

Do you perhaps have some example as to how to access the EC register space?

Hum .. maybe, the best way to know would be to dump it in various hardware states.

Quoted 18 lines

Quoted 2 lines

Quoted 2 lines

ERQ0 (present in BUF1) is compared to Arg2 (BY09) == 0x1 if true, it will store some values and call notify

So this would then trigger the WMI event in the driver, right? I'd assume that EVID is the EVent ID - would make sense, since somewhere in the embedded controller code, there's this snippet:

       Method (_QEF, 0, NotSerialized)
       {
               Store (0xEF, P80H)
               \_SB.WMI2.CMD2 (0x2D, 0x01, 0x01)
       }

       Method (_QF1, 0, NotSerialized)
       {
               Store (0xF1, P80H)
               \_SB.WMI2.CMD2 (0x2C, 0x01, 0x01)
       }

Quoted 3 lines

AFAICT the problem might be that ERQ0 is never initialized.. so it's probably zero from the start and the first code branch in CMD0 will never be called.

ERQ0 is initialized here (with 0x00):

                        Name (BUF1, Buffer (0x40)

	Method (_Q8F, 0, NotSerialized)
	{
		Store ("_Q8F : Hot Key Event", Debug)
		Store (0x8F, P80H)
		DSGO ()
		DSSV ()
		Store ("_Q8F : Hot Key Event Finished", Debug)
	}

IIRC all _Qxx methods are also some kind of notification system, right?

Yes, _Q indicates that it's an embedded controller event (_L and _E are level or edge triggered events from GPEs). Unless either DSGO or DSSV trigger a notification I'd hope that the EC fires some other event after the hotkey has been stored.

Thanks - now let me try to sum this up in order to get it straight (I've been reading the ACPI spec and had to fight sleep really hard :-).

1. EC detects an event (hotkey), raises an SCI.

2. Linux ec.c driver services the SCI, queries the EC for event code.

3. If available, ec.c calls ACPI _Qxx method for received event code.

4. _Qxx method changes some internal state and MAY again call Notify(...) to pass the event to some other ACPI device.

5. If Notify() was called, second-level ACPI driver (e.g. battery.c, thermal.c, ...) gets event and handles it accordingly.

If that's correct so far, couldn't I just print the EC event code in acpi_ec_sync_query and see what it's spitting out on hotkey press?

Quoted 2 lines

If that's correct so far, couldn't I just print the EC event code in acpi_ec_sync_query and see what it's spitting out on hotkey press?

Yes, that should work.

So it would be all joy and happiness if it weren't for the fact that ERQ0 is initialized to zero and is never changed anywhere else.. I'll give the VPC0._CFG method a try later today and see if that changes anything.

What's also confusing is that while there's an EC register (0xE6) which nicely reflects all of the hotkeys' state as a bitmask, one of them doesn't trigger an EC event. I'm reluctant to just write stuff to the EC registers, but maybe one of you can make some sense of the attached hexdump - it says "SANYO" somewhere in there, does that ring a bell?

Since I've seen that lenovo-sl-laptop also just uses polling at 5 Hz to handle the hotkeys, I'm sort of leaning towards that solution now..

There's 4 dedicated hotkeys. Of these, one generates KEY_F8 for no particular reason, one (correctly!) generates KEY_MUTE, one just generates an 0x95 event that dies as described before and the fourth one (which _does_ work in Splashtop!) does nothing at all.

I also think so in general, but in this case, the entire notification setup looks like an incredible mess to me. In any other case, I wouldn't really bother with the hotkeys, but as this is a tablet PC, the hotkeys on the screen side become really important all of a sudden...

Hm. Yeah, that looks pretty messed up. I think you'd be justified in just changing that entry yourself, to be honest, and then see if that makes things behave more usefully.

You mean, change the initial value for ERQ0 in the DSDT and load that through the kernel? I'll try that. I'll also try a BIOS update and see if there's a little more sense in the DSDT afterwards..

Quoted 4 lines · Florian Echtler

I also think so in general, but in this case, the entire notification setup looks like an incredible mess to me. In any other case, I wouldn't really bother with the hotkeys, but as this is a tablet PC, the hotkeys on the screen side become really important all of a sudden...

Yeah. I'll take a look and see if there's anything obvious.