Hi. I have a problem with Sleep button events. dmesg shows this: ug 16 22:44:27 lapek ACPI: AC Adapter [ADP1] (off-line) Aug 16 22:44:27 lapek ACPI: Battery Slot [BAT0] (battery present) Aug 16 22:44:27 lapek ACPI: Power Button (FF) [PWRF] Aug 16 22:44:27 lapek ACPI: Lid Switch [LID0] Aug 16 22:44:27 lapek ACPI: Sleep Button (CM) [SLPB] Moreover: Aug 16 22:44:27 lapek input: Power Button (FF) as /class/input/input0 Aug 16 22:44:27 lapek input: Lid Switch as /class/input/input1 Aug 16 22:44:27 lapek input: Sleep Button (CM) as /class/input/input2 Aug 16 22:44:27 lapek input: AT Translated Set 2 keyboard as /class/input/input3 Aug 16 22:44:27 lapek input: SynPS/2 Synaptics TouchPad as /class/input/input4 When I do cat /dev/input/event* I can see events on input1 generated by lid on input0 generated by power button but no events on input2 :( In fact all events from Sleep button go input3 (normal keyboard input) and are transleted to system trough this. Sleep button generates KEY_SLEEP evnets which is catched by gnome-power-manager so I have suspend functionality in X but no in "pure" console mode (no X running). How can I make these events to be generated on input2? Regards Michal.
It is possible that the input3 key you are seeing is a different key from what ACPI is reporting. Unfortunately, the system doesn't tell us which physical key is associated with SLPB, so lets go hunt for it... Please kill acpid and cat /proc/acpi/event then press every possible key and function key on the keyboard to see if any of them give you a sleep button event. Please also describe the exact system that has this problem. We may find also that output from acpidump will be helpful.
I tried killing acpid and catting /proc/acpi/event. The only thing that generates acpi events is lid and power button. For my laptop the hibernation key combination is Fn+f4 and it only generates KEY_SLEEP event. I heard (from acpi guys) that it is common for some laptops. So maybe kernel should also generate acpi event in such cases (in example by handling KEY_SLEEP event?). I read that hal uses this technic to pass suspend event trough dbus to other program. For instance this is how gnome-power-manager gets this info and hibernates my laptop.
Did you run this test with the acpi video driver loaded? Can you give the make & model of the system and attache the acpidump output please?
Created attachment 12613 [details] My acpidump
I did not load acpi video driver. I use Gentoo with kernel 2.6.22.
So with X running FnF4 makes it to X as KEY_SLEEP and everybody is happy. But without X, you want the sleep button to give events on input3 like the dmesg says it should, and FnF4 doesn't give those events?
>When I do cat /dev/input/event* I can see events on input1 generated >by lid on input0 generated by power button but no events on input2 :( This means no acpi events happen on ACPI sleep button. >In fact all events from Sleep button go input3 (normal keyboard input) Hmm, all events from sleep button should go to input2. Only events from keyboard driver should go input3. What you see means KEP_SLEEP events are generated by keyboard driver. That's common on many systems. It just means pressing Fn+F4 generate an interrupt to i8042 controller rather than ACPI. In other words, ACPI is not aware of the Fn+F4 key pressing, while this is full handled by the keyboard driver. Please note that ACPI is not the only one that can generate KEY_SLEEP events. thinkpad_acpi driver and keyboard driver can do the same thing as well. >and are transleted to system trough this. Sleep button generates >KEY_SLEEP evnets which is catched by gnome-power-manager so I have >suspend functionality in X but no in "pure" console mode (no X Yes, that's right except that the KEY_SLEEP event is actually generated by the keyboard driver(input3). something like "AT Translated Set 2 keyboard"? >running). How can I make these events to be generated on input2? No, we can't. It's hardware that sends the interrupt to i8042 controller rather than ACPI.
Fn+F4 is not ACPI hotkey. And KEY_SLEEP event generated by keyboard driver is discarded in console mode. I think it's a problem that we won't fix. Michal, please reopen it if you still have any questions. :)