While searching for something I did not find, I came across Canonical voices page and an explanation of how suspend and resume work in Linux.
The sleep key "is bounced back out to userspace via /proc/acpi/events (currently, though it's going to be moved to the input layer in future) and userspace gets to choose what happens next.
Let's concentrate on the common scenario, which is that someone hitting the sleep button wants to suspend to RAM. Via some abstraction (either acpid, gnome-power-manager or kpowersave or something), userspace makes that decision and initiates the suspend to RAM process by either calling a suspend script directly or bouncing via HAL." (http://www.advogato.org/article/913.html)
Hence, it is possible that a different window manager on the same hardware may behave differently. And, of course, the behaviour on different distributions can be different.
I also came across a presentation on how notebook's lid and special buttons work which gives an insight into how the hardware generates the general purpose events.
On Lenovo S10-3, the sleep key (Fn+F1) worked on each on the os's. However, the lid works perfectly well with Ubuntu, MeeGo and Smeegol but doesn't with Arch Linux even though laptop-mode tools, acpid are installed. On Ubuntu 10.10 using gdm, if I start kde, even (Fn+F1) does not work!
Thanks to the above information, I can start my hunt for why and, perhaps, a consistent solution for S10-3 no matter what the distribution or the window manager.
Subscribe to:
Post Comments (Atom)
These articles are also useful:
ReplyDeletehttps://wiki.ubuntu.com/Kernel/Reference/S3
https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
http://smackerelofopinion.blogspot.com/search/label/resume