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: | kbd | Assignee: | Vitezslav Crhonek <vcrhonek> |
Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 5.6 | CC: | 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
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. 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. This issue still exists with the new kernel in place. The error appears exactly as before. Hi, there is a solution for this problem: http://de.gentoo-wiki.com/Microsoft_Wireless_Desktop_Elite_Keyboard Cheers, Liviu 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 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. 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. 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. The issue still exists as described above. No change has been observed. 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. 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. 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. 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. 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. http://packages.debian.org/unstable/misc/hotkey-setup setups keycodes based on DMI info. 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). 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. 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. 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 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. Steve, which version of Fedora are you using? 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. At the time I was using FC4. Fedora Core 4, 5, 6 and 7 are no longer maintained. Is this bug still present in Fedora 8 or 9? I no longer run fedora so I do not know. I run RHEL4 and the issue still exist there if that helps at all. Fedora 11 and this bug is still present. *** Bug 509038 has been marked as a duplicate of this bug. *** 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. *** Bug 679281 has been marked as a duplicate of this bug. *** 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/ |