Red Hat Bugzilla – Full Text Bug Listing
|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:||kbd||Assignee:||Vitezslav Crhonek <vcrhonek>|
|Status:||CLOSED WONTFIX||QA Contact:||qe-baseos-daemons|
|Version:||5.6||CC:||davej, imatusov, jiannma, mcepl, notting, ovasik, skomrowski, wtogami|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-03-12 08:20:18 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Steve Thrasher 2004-12-01 12:55:58 EST
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 16:06:12 EDT
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 03:05:29 EDT
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 14:15:40 EDT
This issue still exists with the new kernel in place. The error appears exactly as before.
Comment 4 Liviu Coman 2005-08-23 16:32:48 EDT
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 17:07:54 EDT
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 17:37:57 EST
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 01:58:24 EST
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 11:03:38 EST
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 15:39:39 EST
The issue still exists as described above. No change has been observed.
Comment 10 Dave Jones 2006-02-27 00:22:27 EST
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 17:58:00 EST
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 18:00:32 EST
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 18:38:01 EST
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-27 20:08:47 EST
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 17:34:03 EST
http://packages.debian.org/unstable/misc/hotkey-setup setups keycodes based on DMI info.
Comment 16 Mikel Ward 2006-11-04 19:36:28 EST
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 06:16:23 EST
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 11:27:23 EST
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-03 21:52:50 EDT
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 11:28:26 EDT
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 15:09:01 EDT
Steve, which version of Fedora are you using?
Comment 22 Matěj Cepl 2008-07-02 03:08:25 EDT
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 00:15:21 EDT
At the time I was using FC4.
Comment 24 petrosyan 2008-07-08 00:23:23 EDT
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 17:24:49 EDT
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 06:09:39 EDT
Fedora 11 and this bug is still present.
Comment 27 Kevin Fenzi 2009-07-01 11:35:14 EDT
*** Bug 509038 has been marked as a duplicate of this bug. ***
Comment 28 Ondrej Vasik 2010-03-18 11:59:21 EDT
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 10:51:42 EST
*** Bug 679281 has been marked as a duplicate of this bug. ***
Comment 31 Vitezslav Crhonek 2013-03-12 08:20:18 EDT
RHEL-5 is entering Production 2 Phase (see ), only critical and important security issues are going to be adressed => closing this bug WONTFIX.  https://access.redhat.com/support/policy/updates/errata/