On Tue, Apr 20, 2010 at 9:21 AM, Corentin Chary <corentin.chary@xxxxxxxxx> wrote: > On Tue, Apr 20, 2010 at 8:52 AM, Florian Echtler <floe@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
