Martins Krikis wrote:
Hmm. Some good points there.
No, I wasn't running any of those, in fact kpowersave (which turns out to be
a tray applet) wasn't even installed and Gnome still isn't. When logging out
of X and pressing the button while logged on the VT, nothing happened.
Then I logged back on to X, installed this kpowersave and launched.
I already had some other KDE battery monitor tray applet running,
so this was now a second one. But it did indeed start handling the
keypress generated by acpi_fakekey. So the laptop suspends again.
(It's a pity the battery charge amount that this applet shows and the
number of batteries installed seems to mismatch reality but that's a
different bug and story.)
So is Debian's acpi-support design for suspend-to-ram such that it _only_
works in X and only if the user has installed some particular
utilities to grab the
generated fakekey? Now I'm really getting interested in how could it have worked
with the 2.6.22.5 kernel. And what is the purpose of
/etc/acpi/sleep.sh, since it
didn't seem to get involved in the suspend-to-ram orchestrated by kpowersave.
The role is to handle the key if nobody else does. Apparently this goes
wrong in newer kernels. I've heard some things about a recent rewiring
of certain event chains, we'll simply have to figure out how the wiring
currently works. Once I get to my own computer I'll try to figure it out!
Cheers,
Bart
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
