* Looking for some pointers on WMI/EC access @ 2010-04-17 15:37 Florian Echtler 2010-04-18 19:21 ` Corentin Chary 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-17 15:37 UTC (permalink / raw) To: linux-acpi 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? Yours, Florian (*) The Splashtop kernel is obfuscated in the most stupid way imaginable: XOR "encryption" with 'QWER' as key. Need I say more? -- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-17 15:37 Looking for some pointers on WMI/EC access Florian Echtler @ 2010-04-18 19:21 ` Corentin Chary 2010-04-19 14:25 ` Florian Echtler 0 siblings, 1 reply; 23+ messages in thread From: Corentin Chary @ 2010-04-18 19:21 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-18 19:21 ` Corentin Chary @ 2010-04-19 14:25 ` Florian Echtler 2010-04-19 15:46 ` Corentin Chary 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-19 14:25 UTC (permalink / raw) To: Corentin Chary; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-19 14:25 ` Florian Echtler @ 2010-04-19 15:46 ` Corentin Chary [not found] ` <1271746353.16585.9.camel@flunder> 0 siblings, 1 reply; 23+ messages in thread From: Corentin Chary @ 2010-04-19 15:46 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <1271746353.16585.9.camel@flunder>]
* Re: Looking for some pointers on WMI/EC access [not found] ` <1271746353.16585.9.camel@flunder> @ 2010-04-20 7:21 ` Corentin Chary 2010-04-20 7:30 ` Corentin Chary 0 siblings, 1 reply; 23+ messages in thread From: Corentin Chary @ 2010-04-20 7:21 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-20 7:21 ` Corentin Chary @ 2010-04-20 7:30 ` Corentin Chary 2010-04-20 11:21 ` Florian Echtler 0 siblings, 1 reply; 23+ messages in thread From: Corentin Chary @ 2010-04-20 7:30 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-20 7:30 ` Corentin Chary @ 2010-04-20 11:21 ` Florian Echtler 2010-04-20 12:09 ` Corentin Chary 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-20 11:21 UTC (permalink / raw) To: Corentin Chary; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-20 11:21 ` Florian Echtler @ 2010-04-20 12:09 ` Corentin Chary 2010-04-21 12:46 ` Florian Echtler 0 siblings, 1 reply; 23+ messages in thread From: Corentin Chary @ 2010-04-20 12:09 UTC (permalink / raw) To: Florian Echtler; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-20 12:09 ` Corentin Chary @ 2010-04-21 12:46 ` Florian Echtler 2010-04-21 13:33 ` Matthew Garrett 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-21 12:46 UTC (permalink / raw) To: Corentin Chary; +Cc: linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-21 12:46 ` Florian Echtler @ 2010-04-21 13:33 ` Matthew Garrett 2010-04-21 14:30 ` Florian Echtler 0 siblings, 1 reply; 23+ messages in thread From: Matthew Garrett @ 2010-04-21 13:33 UTC (permalink / raw) To: Florian Echtler; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-21 13:33 ` Matthew Garrett @ 2010-04-21 14:30 ` Florian Echtler 2010-04-21 14:32 ` Matthew Garrett 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-21 14:30 UTC (permalink / raw) To: Matthew Garrett; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 > 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-21 14:30 ` Florian Echtler @ 2010-04-21 14:32 ` Matthew Garrett 2010-04-22 8:21 ` Florian Echtler 0 siblings, 1 reply; 23+ messages in thread From: Matthew Garrett @ 2010-04-21 14:32 UTC (permalink / raw) To: Florian Echtler; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-21 14:32 ` Matthew Garrett @ 2010-04-22 8:21 ` Florian Echtler 2010-04-22 13:36 ` Matthew Garrett 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-22 8:21 UTC (permalink / raw) To: Matthew Garrett; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 [-- 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-22 8:21 ` Florian Echtler @ 2010-04-22 13:36 ` Matthew Garrett [not found] ` <1271944219.29664.42.camel@pancake.fritz.box> 0 siblings, 1 reply; 23+ messages in thread From: Matthew Garrett @ 2010-04-22 13:36 UTC (permalink / raw) To: Florian Echtler; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
[parent not found: <1271944219.29664.42.camel@pancake.fritz.box>]
* Re: Looking for some pointers on WMI/EC access [not found] ` <1271944219.29664.42.camel@pancake.fritz.box> @ 2010-04-22 13:53 ` Matthew Garrett 2010-04-22 14:05 ` Matthew Garrett 2010-04-22 14:33 ` Corentin Chary 0 siblings, 2 replies; 23+ messages in thread From: Matthew Garrett @ 2010-04-22 13:53 UTC (permalink / raw) To: Florian Echtler; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-22 13:53 ` Matthew Garrett @ 2010-04-22 14:05 ` Matthew Garrett 2010-04-23 11:24 ` Florian Echtler 2010-04-22 14:33 ` Corentin Chary 1 sibling, 1 reply; 23+ messages in thread From: Matthew Garrett @ 2010-04-22 14:05 UTC (permalink / raw) To: Florian Echtler; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-22 14:05 ` Matthew Garrett @ 2010-04-23 11:24 ` Florian Echtler 2010-04-23 17:47 ` Matthew Garrett 0 siblings, 1 reply; 23+ messages in thread From: Florian Echtler @ 2010-04-23 11:24 UTC (permalink / raw) To: Matthew Garrett; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-23 11:24 ` Florian Echtler @ 2010-04-23 17:47 ` Matthew Garrett 0 siblings, 0 replies; 23+ messages in thread From: Matthew Garrett @ 2010-04-23 17:47 UTC (permalink / raw) To: Florian Echtler; +Cc: Corentin Chary, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-04-22 13:53 ` Matthew Garrett 2010-04-22 14:05 ` Matthew Garrett @ 2010-04-22 14:33 ` Corentin Chary 1 sibling, 0 replies; 23+ messages in thread From: Corentin Chary @ 2010-04-22 14:33 UTC (permalink / raw) To: Matthew Garrett; +Cc: Florian Echtler, linux-acpi, platform-driver-x86 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access
@ 2010-12-01 0:16 Javier S. Pedro
2010-12-01 1:31 ` Matthew Garrett
0 siblings, 1 reply; 23+ messages in thread
From: Javier S. Pedro @ 2010-12-01 0:16 UTC (permalink / raw)
To: platform-driver-x86; +Cc: floe, mjg59
(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.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-12-01 0:16 Javier S. Pedro @ 2010-12-01 1:31 ` Matthew Garrett 2010-12-01 20:13 ` Javier S. Pedro 0 siblings, 1 reply; 23+ messages in thread From: Matthew Garrett @ 2010-12-01 1:31 UTC (permalink / raw) To: Javier S. Pedro; +Cc: platform-driver-x86, floe 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-12-01 1:31 ` Matthew Garrett @ 2010-12-01 20:13 ` Javier S. Pedro 2010-12-01 20:19 ` Matthew Garrett 0 siblings, 1 reply; 23+ messages in thread From: Javier S. Pedro @ 2010-12-01 20:13 UTC (permalink / raw) To: Matthew Garrett; +Cc: platform-driver-x86, floe 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: Looking for some pointers on WMI/EC access 2010-12-01 20:13 ` Javier S. Pedro @ 2010-12-01 20:19 ` Matthew Garrett 0 siblings, 0 replies; 23+ messages in thread From: Matthew Garrett @ 2010-12-01 20:19 UTC (permalink / raw) To: Javier S. Pedro; +Cc: platform-driver-x86, floe 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 ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2010-12-01 20:19 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-17 15:37 Looking for some pointers on WMI/EC access Florian Echtler 2010-04-18 19:21 ` Corentin Chary 2010-04-19 14:25 ` Florian Echtler 2010-04-19 15:46 ` Corentin Chary [not found] ` <1271746353.16585.9.camel@flunder> 2010-04-20 7:21 ` Corentin Chary 2010-04-20 7:30 ` Corentin Chary 2010-04-20 11:21 ` Florian Echtler 2010-04-20 12:09 ` Corentin Chary 2010-04-21 12:46 ` Florian Echtler 2010-04-21 13:33 ` Matthew Garrett 2010-04-21 14:30 ` Florian Echtler 2010-04-21 14:32 ` Matthew Garrett 2010-04-22 8:21 ` Florian Echtler 2010-04-22 13:36 ` Matthew Garrett [not found] ` <1271944219.29664.42.camel@pancake.fritz.box> 2010-04-22 13:53 ` Matthew Garrett 2010-04-22 14:05 ` Matthew Garrett 2010-04-23 11:24 ` Florian Echtler 2010-04-23 17:47 ` Matthew Garrett 2010-04-22 14:33 ` Corentin Chary 2010-12-01 0:16 Javier S. Pedro 2010-12-01 1:31 ` Matthew Garrett 2010-12-01 20:13 ` Javier S. Pedro 2010-12-01 20:19 ` Matthew Garrett
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.