Bug 141505

Summary: atkbd.c: Unknown key pressed (translated set 2, code 0xd9 on isa0060/serio0).
Product: Red Hat Enterprise Linux 5 Reporter: Steve Thrasher <thrash>
Component: kbdAssignee: Vitezslav Crhonek <vcrhonek>
Status: CLOSED WONTFIX QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: medium    
Version: 5.6CC: davej, imatusov, jiannma, mcepl, notting, ovasik, skomrowski, wtogami
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-03-12 12:20:18 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:

Description Steve Thrasher 2004-12-01 17:55:58 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20041020

Description of problem:
Dell Laptop using Wireless KB/Mouse via KVM generates the following
pair of messages intermittently in the /var/log/messages log during
normal use:

Dec  1 09:25:50 biglaptop kernel: atkbd.c: Unknown key pressed
(translated set 2, code 0xd9 on isa0060/serio0).
Dec  1 09:25:50 biglaptop kernel: atkbd.c: Use 'setkeycodes e059
<keycode>' to make it known.

These messages disappear when a "wired" KB/Mouse are used.  The
KB/Mouse models are MS Wireless Intellimouse 2.0 and MS Wireless
Natural Multimedia Keyboard.

There seems to be no coorelation between keys pressed and the message
generation.  It seems to be random.

Version-Release number of selected component (if applicable):
kernel-2.6.9-1.681_FC3

How reproducible:
Always

Steps to Reproduce:
1.Use the KB/Mouse combo noted above.
2.
3.
    

Actual Results:  Dec  1 09:25:50 biglaptop kernel: atkbd.c: Unknown
key pressed (translated set 2, code 0xd9 on isa0060/serio0).
Dec  1 09:25:50 biglaptop kernel: atkbd.c: Use 'setkeycodes e059
<keycode>' to make it known.

Expected Results:  No error in the logs

Additional info:

This issue hinders normal CLI sessions as it appears as you are tying
on the command line (not in X) or using vi.  It's not a show stopper
but it is quite annoying.

Comment 1 Dave Jones 2005-07-15 20:06:12 UTC
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem.   Please update to this new kernel, and
report whether or not it fixes your problem.

If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.

Thank you.

Comment 2 Mikel Ward 2005-07-23 07:05:29 UTC
Can the reporter verify whether this issue still exists in Fedora.

This is a problem in many distributions and is a common topic on forums.

These events seem to be ACPI power notifications, hence only occuring for
wireless (battery operated) keyboards.

Since there's currently nothing to handle these events under Linux, I drop them
on the floor by adding
setkeycodes e059 120
setkeycodes e001 121

to my startup scripts (e.g. /etc/init.d/winkeys) on Ubuntu.  I assume something
similar works for Fedora.


Comment 3 Steve Thrasher 2005-07-29 18:15:40 UTC
This issue still exists with the new kernel in place.  The error appears 
exactly as before.

Comment 4 Liviu Coman 2005-08-23 20:32:48 UTC
Hi,

there is a solution for this problem:
http://de.gentoo-wiki.com/Microsoft_Wireless_Desktop_Elite_Keyboard

Cheers,
Liviu

Comment 5 Liviu Coman 2005-08-31 21:07:54 UTC
I'm having this problem with Fedora Core 4. I have Microsoft Wireless Comfort
Keyboard + Mouse.

atkbd.c: Unknown key pressed (translated set 2, code 0xd9 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e059 <keycode>' to make it known.

We need this fix also for FC4!

Thanks in advance.

Cheers,
Liviu

Comment 6 Dave Jones 2006-01-16 22:37:57 UTC
This is a mass-update to all currently open Fedora Core 3 kernel bugs.

Fedora Core 3 support has transitioned to the Fedora Legacy project.
Due to the limited resources of this project, typically only
updates for new security issues are released.

As this bug isn't security related, it has been migrated to a
Fedora Core 4 bug.  Please upgrade to this newer release, and
test if this bug is still present there.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

Thank you.


Comment 7 Dave Jones 2006-02-03 06:58:24 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO_REPORTER state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.


Comment 8 Tommy 2006-02-25 16:03:38 UTC
This is still an issue even in FC5 Test 3.  I'm using the MS Wireless comfort
keyboard and the kernel spits out messages ala

atkbd.c: Unknown key pressed (translated set 2, code 0xd9 on isa0060/serio0).
atkbd.c: Use 'setkeycodes e059 <keycode>' to make it known.

anytime I type.

Comment 9 Steve Thrasher 2006-02-25 20:39:39 UTC
The issue still exists as described above.  No change has been observed.

Comment 10 Dave Jones 2006-02-27 05:22:27 UTC
googling brought up this ..

http://rob.thesnows.org/?m=200412

which shows how to map those keys to something useful.

Longterm, we should support multimedia keys out-of-the-box.  It's not a kernel
problem though, but a lack of keymap setup.


Comment 11 Miloslav Trmač 2006-02-27 22:58:00 UTC
The issues with having a default mapping of these keys in user-space are exactly
the same as with having a default mapping of them built-in in the kernel: there
are conflicts.

I think we could add a directory where configuration for setkeycodes is specified,
to be handled by rc.sysinit at boot.  Then specific "foo-laptop-support" packages,
if anyone creates such a thing, could just put files in the directory.

Comment 12 Bill Nottingham 2006-02-27 23:00:32 UTC
Ooh, we could read the keyboard type out of the input layer, and have udev
events to load keyboard specific mappings when it's plugged in.

Yes, I'm crazy.


Comment 13 Miloslav Trmač 2006-02-27 23:38:01 UTC
That would be great...  Now only to set up a gigantic keyboard database.
I have only two keyboards, neither requires special setkeycodes invocations.

For AT keyboards we have only a 2-byte ID, which is probably 0xab41 or 0xab83
for most keyboards (including my laptop). For laptops we can match on DMI info,
for external keyboards we probably have no more clues.

Comment 14 Tommy 2006-02-28 01:08:47 UTC
For my part, I don't care about having any of the special multimedia keys on my
keyboard work out of the box.  It would be nice, but there's enough
documentation floating around out there on how to do it if people want to.  I
just think something should be done about the ACPI notifications as described in
Comments 2 and 5, because these events aren't generated by the user in any way,
and it causes the keyboard to behave erratically.  If the user didn't know to
check dmesg, I suspect the problem would be very hard to identify.

Comment 15 Miloslav Trmač 2006-03-09 22:34:03 UTC
http://packages.debian.org/unstable/misc/hotkey-setup
setups keycodes based on DMI info.

Comment 16 Mikel Ward 2006-11-05 00:36:28 UTC
Debian's hotkey-setup doesn't fix this problem.  It just adds support for keys
like sleep, play and pause on the most common laptops.  It doesn't address power
messages for wireless keyboards (which are also used for desktops).

Comment 17 Christian Iseli 2007-01-22 11:16:23 UTC
This report targets the FC3 or FC4 products, which have now been EOL'd.

Could you please check that it still applies to a current Fedora release, and
either update the target product or close it ?

Thanks.

Comment 18 Steve Thrasher 2007-01-22 16:27:23 UTC
The issue still exists.  The only time I really notice (aside from all the 
excess logging) is when I am at the command line outside an X session.  The 
errors populate the screen randomly (not when a specific key is pressed) which 
makes things (especially vi sessions) ugly.

Comment 19 Bug Zapper 2008-04-04 01:52:50 UTC
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers

Comment 20 Bug Zapper 2008-05-06 15:28:26 UTC
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 21 petrosyan 2008-06-17 19:09:01 UTC
Steve, which version of Fedora are you using?

Comment 22 Matěj Cepl 2008-07-02 07:08:25 UTC
Reporter, could you please reply to the previous question? If you won't reply in
one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

Comment 23 Steve Thrasher 2008-07-08 04:15:21 UTC
At the time I was using FC4.

Comment 24 petrosyan 2008-07-08 04:23:23 UTC
Fedora Core 4, 5, 6 and 7 are no longer maintained.
Is this bug still present in Fedora 8 or 9?

Comment 25 Steve Thrasher 2008-07-08 21:24:49 UTC
I no longer run fedora so I do not know.  I run RHEL4 and the issue still exist
there if that helps at all.

Comment 26 Riku Seppala 2009-06-16 10:09:39 UTC
Fedora 11 and this bug is still present.

Comment 27 Kevin Fenzi 2009-07-01 15:35:14 UTC
*** Bug 509038 has been marked as a duplicate of this bug. ***

Comment 28 Ondrej Vasik 2010-03-18 15:59:21 UTC
Moved to RHEL-5.

RHEL-4.9 is last update for RHEL-4 and it is not suitable for new features
and should address only security, performance and critical issues.

Comment 30 Vitezslav Crhonek 2011-02-22 15:51:42 UTC
*** Bug 679281 has been marked as a duplicate of this bug. ***

Comment 31 Vitezslav Crhonek 2013-03-12 12:20:18 UTC
RHEL-5 is entering Production 2 Phase (see [1]), only critical and important security issues are going to be adressed => closing this bug WONTFIX.

[1] https://access.redhat.com/support/policy/updates/errata/