Sorry for I am late reply... 於 四，2012-02-23 於 12:03 -0500，Kyle Evans 提到： > Thank you Joey for sharing these debug methods. > > > You might need check those buttons emit Q event or WMI event. > > > > watch -n 1 cat /sys/firmware/acpi/interrupts/gpe_all > > watch -n 1 cat /sys/firmware/acpi/interrupts/gpe[0123][0123456789ABCDEF] > > > > The value should increased when you press hotkey. > > Then reference Corentin's article: http://lwn.net/Articles/391230/ > > > I found that nothing happens in gpe_all when I push a hotkey button. I > also found that GPE03 calls _Q15. _Q15 is the wireless switch method, > which I have reprogrammed to notify hp-wmi of a keypress. Where is it > defined that GPE03 runs method _Q15? > Normally, you can check the _GPE number EC device in DSDT: Device (EC0) { Name (_HID, EisaId ("PNP0C09")) Name (_UID, One) ... Name (_GPE, 0x03) <--- here, assume EC link to 0x03 Per my understand, EC firmware will set the value '15' to a EC register then emit a SCI event through 0x03. The acpi/ec.c will handle the event and query the '15' value from EC by query command. After got '15', acpi/ec.c will find out the handler for _Q15 then execute it. So, EC firmware should set the value '15' to register then wait acpi/ec.c to query it. > > Use wmidump to parse out wmi, find out the wmi event we might want to > > listen, the flags should has ACPI_WMI_EVENT. > > > > Then, the hard thing is we need try to poke and try to reverse engineer > > to GUESS the input/output format from event. > I did not run wmidump because first, it was not installed, and second, > because I have determined that the wmi component works. > > > If the EC emit Q event when press hotkey, you can enable acpi debug log: > > acpi.debug_level=0x0000000F acpi.debug_layer=0xffffffff log_buf_len=5M > > > > To monitor which method does it run when you press hotkey. > The EC not emitting a Q event is indeed my problem. It should run > method _Q16, which is defined to notify wmi of a keypress. > Yes, that strange because the value of gpe_all (or gpe03?) didn't increase when press function key. That means EC didn't emit SCI when key press. > > And, it's also possibility for EC direct emit scancode, you can use: > > showkey command to grub it or look at dmesg should has some messages. > The way the DSDT is written, this is not the case. However, this may > be something to look at since the EC is the one that reads the button > via SMBus. I can read the internal code via ec_read(0xA2,tmp), a.k.a > QBBB. > > > Here is my current thinking, something in the EC should trigger method Yes! > _Q16. Ideally, SMBus should do it when it receives the button code. > Unfortunately, that function looks like it started with ACPIspec-2 > section 5.6.2.2.2. Although the manufacturer's website indicates the > EC, ENE KB3926 supports ACPI v2, my dsdt.dsl only indicates ACPI v1. > Another possibility, although probably not, is that the buttons also > trigger a GPIO when one is pressed and that the correct GPIO pin needs > to be programmed correctly. My final thought is to do polling in the > EC instead of in the kernel by programming one of the GP Timers to > check for a button press and emit a wmi event in such a case. > > The problem I face now is that the GPIO pin configuration is at > 0xFCxx, and the GPT configuration is at 0xFExx, neither of which can > be accessed with ec_read/write, as it is confined to 0xFFxx. Maybe > there is another function that I do not find? > Sorry for I have no idea. Thanks a lot! Joey Lee -- 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
