GNOME Bugzilla – Bug 331758
Support hibernate and suspend buttons
Last modified: 2006-03-24 11:14:04 UTC
A thinkpad has both hibernate and a suspend button. We should support both in my opinion and not just a sleep button. BTW on my DELL laptop the sleep button is actually called suspend. BTW2 I just looked into the hal spec and there I only see that a sleep button is mentioned. So it might be that support for hibernate and suspend button needs to be added to hal first.
Can you attach your lshal please.
The thinkpad I'm talking about is not in my possesion and doesn't run Linux :-(
Created attachment 59722 [details] IBM x31 lshal output This is the output from my IBM x31 which also has a hibernate button that doesn't work at the moment. The button isn't listed in hal output, nor is it listed in /proc/acpi/button - which only shows lid, power and sleep. However.. acpid knows about the button, as I when I press it (fn+F12) it prints: [Sun Feb 19 18:02:23 2006] received event "ibm/hotkey HKEY 00000080 0000100c" [Sun Feb 19 18:02:23 2006] notifying client 3750[111:111] [Sun Feb 19 18:02:23 2006] executing action "/etc/acpi/hibernatebtn.sh" [Sun Feb 19 18:02:23 2006] BEGIN HANDLER MESSAGES [Sun Feb 19 18:02:23 2006] END HANDLER MESSAGES [Sun Feb 19 18:02:23 2006] action exited with status 0 [Sun Feb 19 18:02:23 2006] completed event "ibm/hotkey HKEY 00000080 0000100c"
So the sleep button is listed in the DSDT and the hibernate button is not... great! A bit of background. HAL currently probes the buttons in the DSDT (entries in /proc/acpi/button) and adds a button device for them in the acpi.c coldplug routine. Then the acpi events are received using the addon, and then matched to a UDI, which is then sent a DeviceCondition. This is where g-p-m kicks in and does the suspend. Ohh, how I love ACPI, because I'm not sure how to solve this one. Ignoring the DSDT might be an option, but I think mjg59 (cc'd) might be able to tell us more. I guess if you manually created a /org/freedesktop/Hal/devices/acpi_HKEY device then the acpi addon would work as it can find a UDI that matches the input. But that's a bodge. So, how do we expose buttons not in the DSDT? Emit them as Conditions against the computer node, or just create the button on the fly (when we recieve the first event). Comments?
The right answer is for the ibm_acpi driver to provide an input device and send keycodes. There's no sensible way to bodge this in via ACPI. (Right now, in Ubuntu we just have acpid events that send keycodes in response to these keys)
>The right answer is for the ibm_acpi driver to provide an input device and > send keycodes. Any hope of getting this upstream? Richard.
It's a fairly easy patch. I'll look into it.
Legend, as long as this is a module option then people should stay happy. Thanks.
I've added hibernate functionality into g-p-m, so now we are just waiting for the kernel/hal bits to come together. If you have a hibernate button on your keyboard, it should "just work" with CVS.
I'll close this FIXED, as we are just waiting for upstream support. And then it should just-work with g-p-m.