Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 445871

Summary:	[T61] Lenova T61 keymapping along with hal-keymap support
Product:	Red Hat Enterprise Linux 5	Reporter:	Alan Matsuoka <alanm>
Component:	hal	Assignee:	Richard Hughes <rhughes>
Status:	CLOSED ERRATA	QA Contact:	desktop-bugs <desktop-bugs>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	5.2	CC:	bmaly, jfeeney, jgarzik, jrb, mclasen, peterm, prarit, rhughes, tao
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2009-01-20 21:53:24 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	450326
Bug Blocks:	391501

Description Alan Matsuoka 2008-05-09 15:09:15 UTC

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 15:10:03 UTC

I'm still working on this. Setting this as a placeholder for 5.3.

Comment 2 RHEL Program Management 2008-06-02 20:00:57 UTC

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 16:12:44 UTC

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 21:53:24 UTC

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