Bug 445871 - [T61] Lenova T61 keymapping along with hal-keymap support
[T61] Lenova T61 keymapping along with hal-keymap support
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: hal (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Richard Hughes
Depends On: 450326
Blocks: 391501
  Show dependency treegraph
Reported: 2008-05-09 11:09 EDT by Alan Matsuoka
Modified: 2013-01-10 02:55 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 16:53:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Matsuoka 2008-05-09 11:09:15 EDT
Description of problem:
The acpi event triggered by pressing FN-F4 is not handled
by a running gnome-power-manager.

How reproducible:

Steps to Reproduce:
- login to gnome
- check if gnome-power-manager is running
- press FN-F4

Actual results:
Nothing happens.

Expected results:
gnome-power-manager should initialize a suspend to RAM.

Additional info:
If you add scripts to /etc/acpi/actions and /etc/acpi/events
FN-F4 is handled by acpid and a proper suspend is triggered.
But if you have configured gnome-power-manager to suspend
after several minutes of inactivity the machine is
suspended a second time right after the resume.

I think as a workaround we can send gnome-power-manager
a signal over dbus. But we have no access to the
"session" bus of the running X-Session. Only the "system"
bus is available.
Comment 1 Alan Matsuoka 2008-05-09 11:10:03 EDT
I'm still working on this. Setting this as a placeholder for 5.3.
Comment 2 RHEL Product and Program Management 2008-06-02 16:00:57 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 11 Richard Hughes 2008-07-31 12:12:44 EDT
After a lot of confusion (some of which mine), I want to make very clear that
#442623 and #445871 are two different problems.

This bug is where the keys are not reported via INPUT, and need kernel support.
This is solved in Fedora 9 using the hal-setup-keycodes binary, a modified
thinkpad_acpi and a whole load of xml keycodes that uses the setkeycodes ioctl
on the custom input device. This does need a kernel changes. This bug DOES NOT
concern computers that get "atkbd.c: Unknown key pressed" in dmesg.

Models this new functionality will fix are listed here:


The difficulty is that thinkpad_acpi is the new driver, and is quite different
from the old ibm_acpi. mjg59, can we look at how easy it would be backporting
the setkeycodes and keymap stuff in thinkpad_acpi into the el5 kernel's ibm_acpi?

Comment 17 errata-xmlrpc 2009-01-20 16:53:24 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.