Hello Bart and all. I know you have a solution pending which will fix
this, but I wanted to add some additional information for frustrated
users like myself who find this bug report from google.
The sleep.sh script is called when the ACPI sleep button is pushed,
i.e., we
get a "button/sleep" event. Many laptops have such an ACPI button, and
for
those laptops, acpi-support's sleep.sh handles the key only if
klaptopdaemon or gnome-power-manager are not running, otherwise it
leaves
the work to those daemons. Apparently this type of laptop doesn't have
an
ACPI sleep button, so we'll have to do something else.
Actually, ThinkPads, with the normal 'button' kernel module, DO have an
ACPI sleep button (fn-f4) which generates a "button/sleep" event (on
the T60 and X60, at least, it is "button/sleep SLPB 00000080
00000001"). The confusion happens because the ibm-acpi (which is called
thinkpad-acpi in kernels after 2.6.18) kernel module, can override that
with it's own ACPI event ("ibm/hotkey HKEY 00000080 00001004").
The ibm-acpi/thinkpad-acpi module doesn't always override the
"button/sleep" event, however. It is possible, at least on some
machines with some versions of ibm-acpi/thinkpad-acpi to mask some keys
so that it does not generate it's own events for them. The
documentation for determining which mask to set to exclude which keys
is not clear. On my version of ibm-acpi (kernel 2.6.18) it is not
possible to mask out the fn-f4 key. It should be possible on later
versions (thinkpad-acpi). Searching the thinkpad-acpi mailing list
archives turns up some useful information.
I suspect the reason [EMAIL PROTECTED] had success with some kernel
versions and not with others is that the default thinkpad-acpi mask for
the kernels that worked excluded fn-f4 so the normal "button/sleep"
event was generated instead of thinkpad-acpi's "HKEY ..." event.
acpi-support includes scripts to handle both events: the standard
"button/sleep" event and ibm-acpi/thinkpad-acpi's "ibm/hotkey ..."
event:
/etc/acpi/events/sleepbtn - handle's "button/sleep" and calls 'sleep.sh'
/etc/acpi/events/ibm-sleepbtn - handle's "ibm/hotkey ..." and calls
'sleepbtn.sh' which generates a key press with acpi_fakekey
That's what had me confused. Why does one call sleep.sh and work as
expected, while the other just generates a key press that does nothing?
They can both be triggered by fn-f4 (depending on if/how ibm-acpi is
enabled) and should both do the same thing. The reason is that acpid is
not the only thing listening to acpi events. Daemons like
HAL/gnome-power-manager also act on "button/sleep" events. That's why
'sleepbtn.sh' simulates the key press, so gnome-power-manager et al can
pickup on the event even though it was not the standard "button/sleep"
event.
So, with ibm-acpi/thinkpad-acpi not loaded (or loaded with a mask which
excludes the sleep button), ThinkPads will generate the "button/sleep"
event that is matched by 'sleepbtn' which calls 'sleep.sh' which puts
the computer to sleep as expected. All good.
With ibm-acpi/thinkpad-acpi loaded with a mask that overrides fn-f4,
and with something like gnome-power-manager running, then ThinkPads
will generate the "ibm/hotkey HKEY ..." event that is matched by
'ibm-sleepbtn' which calls acpi fakekey which generates an input key
event that is picked up by the power management daemon which puts the
computer to sleep as expected. All good here too.
However, with ibm-acpi/think-acpi loaded and with a mask to catch the
fn-f4 key, but without a power-management daemon, there is nothing to
act on the key press simulated by 'sleepbtn.sh' (with acpi_fakekey) so
nothing happens. That's the bug here.
- We check if klaptopdaemon or gnome-power-manager are running.
- If so, we generate the keypress with acpi_fakekey, which will be
picked
up by the power daemons.
- If not, we call sleep.sh.
You mean do all of that in /etc/acpi/sleepbtn.sh? That sounds like a
good solution.
You can expect this fix in the next upload.
Cool. Can you explain to me which release that will get uploaded to?
I'm brand new to Debian, but it seems like Stable (etch) doesn't change
much at all, so I assume any uploads will only be available on the
Testing (lenny) repositories. Is that right? If so, what is the correct
thing for us etch users to do? Just fix it however we see fit locally?
For now I've fixed it on my machine by modifying events/ibm-sleepbtn to
call sleep.sh directly (which works because I don't use
gnome-power-manager or friends).
As a curious aside, on my X60t (2.6.18-6-686), with ibm-acpi loaded
with nothing masked out (echo 0xFFFFFFFF > /proc/acpi/ibm/hotkey), when
I close the laptop, acpid receives events from both the button module
("button/lid LID 00000080 00000001") AND ibm-acpi ("ibm/hotkey HKEY
00000080 00005001"). So the normal 'events/lidbtn' does not suffer the
problems that 'sleepbtn' does.
I hope that was clear enough and helps people understand why their
fn-f4 key does not work with some versions of ibm-acpi/thinkpad-acpi
and acpi-support.
Thank for all your work.
- Chris Burkhardt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
