Bug 445871 - [T61] Lenova T61 keymapping along with hal-keymap support
[T61] Lenova T61 keymapping along with hal-keymap support
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: hal (Show other bugs)
5.2
All Linux
medium Severity medium
: rc
: ---
Assigned To: Richard Hughes
desktop-bugs@redhat.com
:
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:
Environment:
Last Closed: 2009-01-20 16:53:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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:
100%

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
release.
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:

http://gitweb.freedesktop.org/?p=hal-info.git;a=blob;f=fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi

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?

Thanks.
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.

http://rhn.redhat.com/errata/RHEA-2009-0190.html

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