Re: Looking for some pointers on WMI/EC access

Re: Looking for some pointers on WMI/EC access

[Javier S. Pedro]

(Rescuing old discussion about some IdeaPad S10-3t firmware weirdness,
where the front keys fire an EC event that is quietly consumed by
DSDT)

Florian Echtler (Thu, 22 Apr 2010 10:21:28 +0200):
> 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..

Just realized that a few lines below ERQ0 some bit fields are defined
(AP[0-7]) that are actually on the same address as the ERQ0 byte. This
makes
a lot of sense as AP[0-7] are written by WSIO (aka what wmi_set_block
calls here).

Just tried setting a random bit of AP* and events started flowing in. Thank you!

Javier.

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Wed, Dec 01, 2010 at 01:16:15AM +0100, Javier S. Pedro wrote:
> (Rescuing old discussion about some IdeaPad S10-3t firmware weirdness,
> where the front keys fire an EC event that is quietly consumed by
> DSDT)
> 
> Florian Echtler (Thu, 22 Apr 2010 10:21:28 +0200):
> > 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..
> 
> Just realized that a few lines below ERQ0 some bit fields are defined
> (AP[0-7]) that are actually on the same address as the ERQ0 byte. This
> makes
> a lot of sense as AP[0-7] are written by WSIO (aka what wmi_set_block
> calls here).
> 
> Just tried setting a random bit of AP* and events started flowing in. Thank you!

Excellent! Send a driver and I'll get it merged.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Javier S. Pedro]

2010/12/1 Matthew Garrett <mjg59@srcf.ucam.org>:
> Excellent! Send a driver and I'll get it merged.

Note that I have read the iasl -d'd DSDT myself, so I ponder if that
forbids me from writing the module (due to unclean room and all that);
either way, here's the source of the test module I used [1].

Only available are the front keys -- with the rotation one not being
fired when not in "tablet mode" (the EC event is not fired, seemingly)
--  and also "tablet mode" detection, mapped of course to
SW_TABLET_MODE.
There's also some kind of orientation detection events that I'm yet to
fully understand but seem nearly useless. I would very much prefer to
read the raw accelerometer values from EC or HDAPS.

Also: should this be a separate "lenovo-wmi" driver or integrated with
lenovo-laptop?

[1] http://gitorious.org/iaps/lsrot/blobs/master/lsrot.c

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Wed, Dec 01, 2010 at 09:13:51PM +0100, Javier S. Pedro wrote:
> 2010/12/1 Matthew Garrett <mjg59@srcf.ucam.org>:
> > Excellent! Send a driver and I'll get it merged.
> 
> Note that I have read the iasl -d'd DSDT myself, so I ponder if that
> forbids me from writing the module (due to unclean room and all that);
> either way, here's the source of the test module I used [1].

We've never really worried about tainting from ACPI - you're writing coe 
that interfaces with that rather than copying any of their code, so it 
should be fine.

> Only available are the front keys -- with the rotation one not being
> fired when not in "tablet mode" (the EC event is not fired, seemingly)
> --  and also "tablet mode" detection, mapped of course to
> SW_TABLET_MODE.
> There's also some kind of orientation detection events that I'm yet to
> fully understand but seem nearly useless. I would very much prefer to
> read the raw accelerometer values from EC or HDAPS.

Ok.

> Also: should this be a separate "lenovo-wmi" driver or integrated with
> lenovo-laptop?

I'd go with lenovo-wmi.

> [1] http://gitorious.org/iaps/lsrot/blobs/master/lsrot.c

Wonderful. I'll take a look.

Thanks!
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Corentin Chary]

On Sat, Apr 17, 2010 at 5:37 PM, Florian Echtler <floe@butterbrot.org> wrote:
> 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:

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

> 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?

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

(ccing platform-x86)
-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Looking for some pointers on WMI/EC access

[Florian Echtler]

Am Sonntag, den 18.04.2010, 21:21 +0200 schrieb Corentin Chary:
> On Sat, Apr 17, 2010 at 5:37 PM, Florian Echtler <floe@butterbrot.org> wrote:
> > 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 ..
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? 

> > 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
Corresponding to the 2nd GUID, there's also a WQIO method in my DSDT
which should return a data block, correct?

> > 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 ...
I've done that, let's see if I will get some response.

Florian
-- 
0666 - Filemode of the Beast

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Looking for some pointers on WMI/EC access

[Corentin Chary]

On Mon, Apr 19, 2010 at 4:25 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Am Sonntag, den 18.04.2010, 21:21 +0200 schrieb Corentin Chary:
>> On Sat, Apr 17, 2010 at 5:37 PM, Florian Echtler <floe@butterbrot.org> wrote:
>> > 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 ..
> 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.

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

> Could this event be disabled somehow?

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

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

Yes, and WCIO methods too.
Check the code of wmi_query_block in wmi.c and grep it in
drivers/platform/x86/ to see how to use it.

See: http://www.microsoft.com/whdc/system/pnppwr/wmi/wmi-acpi.mspx


-- 
Corentin Chary
http://xf.iksaif.net

Re: Looking for some pointers on WMI/EC access

[Corentin Chary]

On Tue, Apr 20, 2010 at 8:52 AM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello Corentin,
>
>> >> > 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.
>> This is not the first laptop with an asus-like dsdt, some Lenovo are
>> supported by asus-laptop.
>> > 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
-- 
Corentin Chary
http://xf.iksaif.net

Re: Looking for some pointers on WMI/EC access

[Corentin Chary]

On Tue, Apr 20, 2010 at 9:21 AM, Corentin Chary
<corentin.chary@gmail.com> wrote:
> On Tue, Apr 20, 2010 at 8:52 AM, Florian Echtler <floe@butterbrot.org> wrote:
>> Hello Corentin,
>>
>>> >> > 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.
>>> This is not the first laptop with an asus-like dsdt, some Lenovo are
>>> supported by asus-laptop.
>>> > 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

//Ooops, message sent, but not finished ... Continuing here:

else it will call UWED with BY08, BY09, BY16.

Then, BY08 is stored in _T_0 which is used to find what code to execute.
Now, you need to look at what each value of _T_0 will do.


Looking at the rest of the dsdt:

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




-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Looking for some pointers on WMI/EC access

[Florian Echtler]

Hello Corentin,

> > 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?

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

> 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?

Thanks, Florian
-- 
0666 - Filemode of the Beast

Re: Looking for some pointers on WMI/EC access

[Corentin Chary]

On Tue, Apr 20, 2010 at 1:21 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello Corentin,
>
>> > 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?

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

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

ERQ0 is initialized here (with 0x00):
                        Name (BUF1, Buffer (0x40)
                        {
                                /* 0000 */      0x01, 0x00, 0x00,
0xFF, 0x00, 0xFF, 0xFF, 0xFF,
                                /* 0008 */      0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                                /* 0010 */      0xFF, 0xFF, 0x00,
0x00, 0x00, 0xFF, 0xFF, 0xFF,
                                /* 0018 */      0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                                /* 0020 */      0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                                /* 0028 */      0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                                /* 0030 */      0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
                                /* 0038 */      0xFF, 0xFF, 0xFF,
0xFF, 0xFF, 0xFF, 0xFF, 0xFF
                        })


>> 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?

Take a look at eeepc-laptop, you can do most of the work with
acpi_evaluate_object (see write_acpi_int/read_acpi_init in
eeepc-laptop).

If you really need to access the EC directly, check ec_write()/ec_read() calls.



-- 
Corentin Chary
http://xf.iksaif.net
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Looking for some pointers on WMI/EC access

[Florian Echtler]

Hello again,

> Hum .. maybe, the best way to know would be to dump it in various
> hardware states.
I've found some time yesterday to give it a try and first had a look at the EC
register space. I've actually managed to find a register which reflects
the state of the hotkeys - it's register 0xE6. I could probably now just
write a driver to poll this at 5 or 10 Hz and be done with it, but that
solution seems a little hackish. The EC register space is probably still
necessary for accelerometer access (I'll try to set the X/Y/ZALM bits to
1 later and see what happens), but I think for hotkeys, an event-based
solution would be better.

> >> > 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.
> 
> ERQ0 is initialized here (with 0x00):
>                         Name (BUF1, Buffer (0x40)
AFAICT it's never accessed anywhere else, right? So it's going to sit
there at 0x00 and the Notify (\_SB.WMI2, 0x80) code will never be
called.

I still have a bit of confusion going on with respect to the difference
between WMI notifications and EC notifications. The Notify() call above
would trigger the WMI notification, but in what way would the kernel be
notified about something like the following:

	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?

Thanks, Yours, Florian
-- 
0666 - Filemode of the Beast

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Wed, Apr 21, 2010 at 02:46:01PM +0200, Florian Echtler wrote:

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Florian Echtler]

> 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?

Florian
-- 
0666 - Filemode of the Beast

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Wed, Apr 21, 2010 at 04:30:06PM +0200, Florian Echtler wrote:
> 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.

Yup. The ec driver is a special case of a GPE going directly to a driver 
rather than being handled by the ACPI core.

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

That's all correct.

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

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Florian Echtler]

[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]

> > 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.
I tried exactly that, and one could say that it was 50% successful. One
of the hotkeys triggers an EC event 0x95, which should lead to the following
ACPI call chain:

// upper hotkey (touchpad)
Method (_Q95, 0, NotSerialized)
{
	Store (0x95, P80H)
	\_SB.WMI2.CMD3 (0x86)
}

Method (CMD3, 1, NotSerialized)
{
	CMD0 (0x19, 0x01, 0x01, 0x01, Arg0)
}

Method (CMD0, 5, Serialized)
{
	If (LAnd (ERQ0, LEqual (Arg2, 0x01)))
	{
		Store (Arg0, EVID)
		Store (Arg1, ACID)
		Store (Arg4, DA01)
		Notify (\_SB.WMI2, 0x80)
	}
	Else
	{
		Acquire (MCD0, 0xFFFF)
		UWED (Arg0, Arg1, Arg4)
		Release (MCD0)
	}
}

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

Florian

[-- Attachment #2: button_both.hex --]
[-- Type: text/plain, Size: 1196 bytes --]

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 80 16 20 53 41 4e 59  |........... SANY|
00000020  4f 00 31 33 00 00 00 00  00 00 00 00 00 00 00 00  |O.13............|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 08 00 00 00  |................|
00000040  82 03 00 75 40 00 00 00  00 00 00 00 00 00 00 00  |...u@...........|
00000050  00 00 00 00 00 00 00 00  33 2d 00 00 00 00 00 00  |........3-......|
00000060  00 00 00 00 01 11 05 05  00 00 01 11 00 00 00 00  |................|
00000070  00 45 00 14 00 c0 00 4a  09 77 00 00 02 30 00 00  |.E.....J.w...0..|
00000080  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000000a0  00 0a 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  90 00 00 00 00 00 03 fd  |................|
000000c0  00 8b fb f1 14 1f 1d 00  00 00 00 00 00 00 00 00  |................|
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000e0  20 1c 00 00 00 00 c2 00  00 80 00 00 00 00 00 00  | ...............|
000000f0  00 00 00 00 fc 22 00 00  00 00 00 00 00 00 00 00  |....."..........|
00000100

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Thu, Apr 22, 2010 at 10:21:28AM +0200, Florian Echtler wrote:

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

Hm. Maybe there's some side-effect that's intended to result in that. 
Can you send me the DSDT? It didn't seem to turn up on the mailing list 
for some reason.

> 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?

Probably the vendor? Which hotkey doesn't generate an event?

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

Mm. Would be preferable to avoid that. We had polling in the Toshiba 
driver for some time until we worked out that there was a method that 
triggered notifications.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Thu, Apr 22, 2010 at 03:50:19PM +0200, Florian Echtler wrote:

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

So two come through the keyboard controller, one generates an EC event 
and one does nothing? I do wonder about firmware engineers sometimes.

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

Thanks,
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Florian Echtler]

Am Donnerstag, den 22.04.2010, 15:05 +0100 schrieb Matthew Garrett:
> 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..

Florian
-- 
0666 - Filemode of the Beast

Re: Looking for some pointers on WMI/EC access

[Matthew Garrett]

On Fri, Apr 23, 2010 at 01:24:30PM +0200, Florian Echtler wrote:

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

More manipulate the buffer directly from the driver. This ought to be 
possible, if a little fiddly.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Looking for some pointers on WMI/EC access

[Corentin Chary]

On Thu, Apr 22, 2010 at 3:53 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, Apr 22, 2010 at 03:50:19PM +0200, Florian Echtler wrote:
>> 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.

It may be linked VPC0._CFG ..
-- 
Corentin Chary
http://xf.iksaif.net