Bug 485010
| Summary: | missing/incorrect keysyms with Microsoft Wireless Keyboard 7000 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ben Liblit <liblit> | ||||||||||
| Component: | xorg-x11-server | Assignee: | Peter Hutterer <peter.hutterer> | ||||||||||
| Status: | CLOSED CANTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||
| Severity: | medium | Docs Contact: | |||||||||||
| Priority: | low | ||||||||||||
| Version: | 26 | CC: | skomrowski, xgl-maint | ||||||||||
| Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||||||||
| Target Release: | --- | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | Linux | ||||||||||||
| URL: | http://www.microsoft.com/hardware/mouseandkeyboard/ProductDetails.aspx?pid=089 | ||||||||||||
| Whiteboard: | |||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
| Doc Text: | Story Points: | --- | |||||||||||
| Clone Of: | Environment: | ||||||||||||
| Last Closed: | 2017-09-05 03:41:09 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: | 904848 | ||||||||||||
| Bug Blocks: | |||||||||||||
| Attachments: |
|
||||||||||||
Please attach the output of xkbcomp -xkb :0 -. And the xev output as well, it's easier for me to parse it than custom-written text summaries. Created attachment 331661 [details]
output of "xkbcomp -xkb :0 -"
Created attachment 331662 [details]
output of "xev"
I've filtered this down to just keyboard-related events. Note that only two keys produce activity visible here. As noted in my original report and "problematic-keys.txt" attachment, most of the keys generate no keypress events at all.
Do you get messages like this in dmesg when you hit those buttons? atkbd.c: Unknown key pressed (translated set 2, code 0x97 on isa0060/serio0). atkbd.c: Use 'setkeycodes e017 ' to make it known. I pressed each of the ten misbehaving keys in sequence, then looked at the output from "dmesg". No "Unknown key pressed" messages appear in that output. I am running fedora 11 and I am getting similar problems. This only happens when I am in a terminal with the X server shut down. Here is my keyboard model: http://www.microsoft.com/hardware/mouseandkeyboard/ProductDetails.aspx?pid=094 I studied the behaviour and it happens when I press any key at random. The messages appear in a certain interval. For example: I would press the backspace key for 30 seconds, and every ~ 8 seconds I would get the unknown key pressed. Then I moved to another key, and the same result. I read where these keyboards are sending a signal through the receiver puck back to the machine to tell it that the battery is still good. An example of my problem is here: https://bugs.launchpad.net/ubuntu/+source/console-data/+bug/70317 Here is a snippet from the link above, my errors are identical, every few seconds no matter what key pressed. atkbd.c: Unknown key released (translated set 2, code 0x81 on isa0060/serio0). atkbd.c: Use 'setkeycodes e001 <keycode>' to make it known. atkbd.c: Unknown key pressed (translated set 2, code 0xd9 on isa0060/serio0). atkbd.c: Use 'setkeycodes e059 <keycode>' to make it known. I am new to fedora and linux in general and I am trying to troubleshoot this problem. I would like to find a log to show my exact error but the best I can do for now is use the example from the link above. Any help is appreciated. Steve Comment #6 is interesting, but seems to describe a completely different bug. It refers to a different keyboard model, and the symptom of periodic atkbd unknown key messages is definitely not present in my original report. I recommend that comment #6 be filed as a distinct, new issue. will do, thanks for the fast response. This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Ben, please run evtest against the device file, then press the buttons and attach the evtest output here. Created attachment 417769 [details]
output of "evtest /dev/input/event3"
As requested, here is the output of "evtest /dev/input/event3" as I pressed each of the problematic keys in turn. There is really not much to see, though. The following problematic keys produced *no* output at all:
- keycap: telephone handset and globe
- keycap: "1"
- keycap: "2"
- keycap: "3"
- keycap: monitor with gadgets sidebar emphasized
- keycap: magnifying glass surrounding "+" sign
- keycap: magnifying glass surrounding "-" sign
- keycap: letters "ABC" with check mark below
The remaining two problematic keys caused "^@" to appear on the console when pressed but did not otherwise seem to do anything picked up by "evtest" as an event:
- keycap: camera
- keycap: file folder with arrow indicating opening
You can see the two "^@" in the attached "evtest.txt" transcript.
The only real key events that evtest seemed to capture was my pressing of LeftControl followed by C to stop it from running once my tests were done. I've left these in the "evtest.txt" transcript as evidence that I really was monitoring the keyboard's event device file, not the event device file for some unrelated peripheral.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Problem still manifests under Fedora 14. Symptoms are similar to those originally described, but there have been a few changes in the details. Some keys produce no "evtest" output at all; some are seen by "evtest" but produce no X keyboard events, and some are seen by both evtest and X but are bound to the wrong X keysym. Here's an updated description of what I am seeing: keycap: telephone handset and globe evtest: none X keycode: none X keysym: none Windows Vista behavior: initiates some sort of voice call? suggested X keysym: XF86Phone keycap: "1" evtest: none X keycode: none X keysym: none Windows Vista behavior: launch user-configured app or URL suggested X keysym: XF86Launch1 keycap: "2" evtest: none X keycode: none X keysym: none Windows Vista behavior: launch user-configured app or URL suggested X keysym: XF86Launch2 keycap: "3" evtest: none X keycode: none X keysym: none Windows Vista behavior: launch user-configured app or URL suggested X keysym: XF86Launch3 keycap: monitor with gadgets sidebar emphasized evtest: none X keycode: none X keysym: none Windows Vista behavior: raises gadgets sidebar suggested X keysym: not sure; any suggestions? keycap: camera evtest: type 1 (Key), code 226 (Media) X keycode: 234 X keysym: X XF86AudioMedia Windows Vista behavior: opens Pictures folder suggested X keysym: XF86Pictures keycap: magnifying glass surrounding "+" sign evtest: type 1 (Key), code 418 (Zoom In) X keycode: none X keysym: none Windows Vista behavior: zooms display in suggested X keysym: XF86ZoomIn keycap: magnifying glass surrounding "-" sign evtest: type 1 (Key), code 419 (Zoom Out) X keycode: none X keysym: none Windows Vista behavior: zooms display out suggested X keysym: XF86ZoomOut keycap: file folder with arrow indicating opening evtest: type 1 (Key), code 134 (Open) X keycode: 142 X keysym: SunOpen Windows Vista behavior: opens a file in the current app suggested X keysym: XF86Open note: a nearby key is correctly bound to XF86Close, so I am suggesting this change mainly for symmetry keycap: letters "ABC" with check mark below evtest: type 1 (Key), code 432 (Spellcheck) X keycode: none X keysym: none Windows Vista behavior: spell-check current document suggested X keysym: XF86Spell (In reply to comment #14) > Problem still manifests under Fedora 14. F14 is EOL. Please check what the current status of this is on F15 or F16, I suspect at least the ones that didn't previously send kernel keycodes (i.e. no evtest events) may be fixed by now. > keycap: magnifying glass surrounding "+" sign > evtest: type 1 (Key), code 418 (Zoom In) > > keycap: magnifying glass surrounding "-" sign > evtest: type 1 (Key), code 419 (Zoom Out) > keycap: letters "ABC" with check mark below > evtest: type 1 (Key), code 432 (Spellcheck) we cannot route this keycode in X, we're limited to codes below 255. See https://bugs.freedesktop.org/show_bug.cgi?id=11227 for more information. > Please check what the current status of this is on F15 or F16, I suspect at > least the ones that didn't previously send kernel keycodes (i.e. no evtest > events) may be fixed by now. Checked under Fedora 16. Almost everything is the same as before. The only changes are to the key labeled with a camera. In comment #14 I said that emitted evtest code 226 (Media), X keycode 234, X keysym XF86AudioMedia. Now it emits evtest code 442, with no X keycode or keysym. Here's an updated description of what I am seeing: keycap: telephone handset and globe evtest: none X keycode: none X keysym: none Windows Vista behavior: initiates some sort of voice call? suggested X keysym: XF86Phone keycap: "1" evtest: none X keycode: none X keysym: none Windows Vista behavior: launch user-configured app or URL suggested X keysym: XF86Launch1 keycap: "2" evtest: none X keycode: none X keysym: none Windows Vista behavior: launch user-configured app or URL suggested X keysym: XF86Launch2 keycap: "3" evtest: none X keycode: none X keysym: none Windows Vista behavior: launch user-configured app or URL suggested X keysym: XF86Launch3 keycap: monitor with gadgets sidebar emphasized evtest: none X keycode: none X keysym: none Windows Vista behavior: raises gadgets sidebar suggested X keysym: not sure; any suggestions? keycap: camera evtest: type 1 (Key), code 442 (Media) X keycode: none X keysym: none Windows Vista behavior: opens Pictures folder suggested X keysym: XF86Pictures keycap: magnifying glass surrounding "+" sign evtest: type 1 (Key), code 418 (Zoom In) X keycode: none X keysym: none Windows Vista behavior: zooms display in suggested X keysym: XF86ZoomIn keycap: magnifying glass surrounding "-" sign evtest: type 1 (Key), code 419 (Zoom Out) X keycode: none X keysym: none Windows Vista behavior: zooms display out suggested X keysym: XF86ZoomOut keycap: file folder with arrow indicating opening evtest: type 1 (Key), code 134 (Open) X keycode: 142 X keysym: SunOpen Windows Vista behavior: opens a file in the current app suggested X keysym: XF86Open note: a nearby key is correctly bound to XF86Close, so I am suggesting this change mainly for symmetry keycap: letters "ABC" with check mark below evtest: type 1 (Key), code 432 (Spellcheck) X keycode: none X keysym: none Windows Vista behavior: spell-check current document suggested X keysym: XF86Spell > we cannot route this keycode in X, we're limited to codes below 255. OK, but notice that the camera key used to produce evtest code 226, and now it produces code 442. The hardware hasn't changed at all. So at least part of this is under *some* piece of software's control. This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Problem still manifests under Fedora 18. (In reply to comment #16) > keycap: file folder with arrow indicating opening > evtest: type 1 (Key), code 134 (Open) > X keycode: 142 > X keysym: SunOpen > Windows Vista behavior: opens a file in the current app > suggested X keysym: XF86Open > note: a nearby key is correctly bound to XF86Close, so I am suggesting this > change mainly for symmetry SunOpen indeed looks weird, but otoh changing this may break things now (couldn't find a client using it though). Filed https://bugs.freedesktop.org/show_bug.cgi?id=59878 For the rest, again, anyting hitting the 255 keycode limit cannot currently be processed by X. Anything that doesn't provide a keycode in evtest needs to be enabled in the kernel first, please file a kernel bug for those. As suggested in comment #19, I have filed bug #904848 for the keys that produce no events under evtest. As of kernel-3.7.4-204.fc18.i686, there are five such keys. So bug #904848 partially blocks this one. Also under kernel-3.7.4-204.fc18.i686, four keys produce evtest keycodes above 255: spell check, zoom in, zoom out, and camera. I understand that these cannot be bound to key events until https://bugs.freedesktop.org/show_bug.cgi?id=11227 is resolved, so that bug also partially blocks this one. All remaining special keys, which produce keycodes below 255, are also bound to reasonable X keysyms by default. There's the possible change of keycode 142 from SunOpen to XF86Open mentioned in comment #16 and comment #19, but even SunOpen is not too bad. So at this point, this bug report is really on hold. Every problem reported here either needs a fix to bug #904848, a fix to https://bugs.freedesktop.org/show_bug.cgi?id=11227, or a fix to https://bugs.freedesktop.org/show_bug.cgi?id=59878. This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Problem still manifests under Fedora 20. The only change from comment #16 seems to be that the keycap showing a file folder with arrow indicating opening now does generate the suggested XF86Open instead of SunOpen. This is surely a consequence of https://bugs.freedesktop.org/show_bug.cgi?id=59878 being fixed. The other non-responsive keys mentioned in comment #16 are still non-responsive, as we wait for future fixes to bug #904848 and https://bugs.freedesktop.org/show_bug.cgi?id=11227. This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Problem still manifests under Fedora 22, although with fewer missing keys than before. Progress! I'm also pleased to say that every key generates events under "evtest", thanks to work on #904848. We're not done yet, though. The following keys still have missing or incorrect keysyms: keycap: "1" evtest: type 1 (EV_KEY), code 184 (KEY_F14) X keycode: 192 X keysym: XF86Launch5 Windows behavior: launch first user-configured app or URL suggested X keysym: XF86Launch1 keycap: "2" evtest: type 1 (EV_KEY), code 185 (KEY_F15) X keycode: 193 X keysym: XF86Launch6 Windows behavior: launch second user-configured app or URL suggested X keysym: XF86Launch2 keycap: "3" evtest: type 1 (EV_KEY), code 186 (KEY_F16) X keycode: 194 X keysym: XF86Launch7 Windows behavior: launch third user-configured app or URL suggested X keysym: XF86Launch3 keycap: camera evtest: type 4 (EV_MSC), code 4 (MSC_SCAN) X keycode: none X keysym: none Windows behavior: opens Pictures folder suggested X keysym: XF86Pictures keycap: magnifying glass surrounding "+" sign evtest: type 1 (EV_KEY), code 418 (KEY_ZOOMIN) X keycode: none X keysym: none Windows behavior: zooms display in suggested X keysym: XF86ZoomIn keycap: magnifying glass surrounding "-" sign evtest: type 1 (EV_KEY), code 419 (KEY_ZOOMOUT) X keycode: none X keysym: none Windows behavior: zooms display out suggested X keysym: XF86ZoomOut keycap: letters "ABC" with check mark below evtest: type 1 (EV_KEY), code 432 (KEY_SPELLCHECK) X keycode: none X keysym: none Windows behavior: spell-check current document suggested X keysym: XF86Spell Oops, I misreported the evtest event for the camera key. Sorry about that! Just to keep it all in one place, here's the corrected complete list of remaining defects: keycap: "1" evtest: type 1 (EV_KEY), code 184 (KEY_F14) X keycode: 192 X keysym: XF86Launch5 Windows behavior: launch first user-configured app or URL suggested X keysym: XF86Launch1 keycap: "2" evtest: type 1 (EV_KEY), code 185 (KEY_F15) X keycode: 193 X keysym: XF86Launch6 Windows behavior: launch second user-configured app or URL suggested X keysym: XF86Launch2 keycap: "3" evtest: type 1 (EV_KEY), code 186 (KEY_F16) X keycode: 194 X keysym: XF86Launch7 Windows behavior: launch third user-configured app or URL suggested X keysym: XF86Launch3 keycap: camera evtest: type 1 (EV_KEY), code 442 (?) X keycode: none X keysym: none Windows behavior: opens Pictures folder suggested X keysym: XF86Pictures keycap: magnifying glass surrounding "+" sign evtest: type 1 (EV_KEY), code 418 (KEY_ZOOMIN) X keycode: none X keysym: none Windows behavior: zooms display in suggested X keysym: XF86ZoomIn keycap: magnifying glass surrounding "-" sign evtest: type 1 (EV_KEY), code 419 (KEY_ZOOMOUT) X keycode: none X keysym: none Windows behavior: zooms display out suggested X keysym: XF86ZoomOut keycap: letters "ABC" with check mark below evtest: type 1 (EV_KEY), code 432 (KEY_SPELLCHECK) X keycode: none X keysym: none Windows behavior: spell-check current document suggested X keysym: XF86Spell 442 is 0x1ba -> KEY_IMAGES. evtest doesn't resolve the name, in the future it's better to use evemu-record here. as said above X can't route keycodes over 255, and the last evdev keycode routable is 255-8. I don't think switching from XF86Launch5 to XF86Launch1 provides much of a benefit other than complicating the layouts. Any client that allows customized commands should support all of them and it doesn't matter what number is assigned, only that the behaviour is consistent. Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. This problem still manifests under Fedora 24. The remaining problematic keys are unchanged from those listed in comment #25. As Peter Hutterer recommended in comment #26, I'm relisting those here using evemu-record instead of evtest. Peter, I am not convinced that XF86Launch[567] are just as good here as XF86Launch[123]. I can use the GNOME Keyboard settings application to assign the first of these launcher keys as a shortcut, and indeed it does work. However, the keyboard shortcut shows up in the settings application as "Launch5", even though the launcher key is labeled "1", not "5". This seems poor for usability. However, if you prefer that I refile this as a distinct bug report, I am happy to do so. keycap: "1" evemu-record: EV_KEY / KEY_F14 X keycode: 192 X keysym: XF86Launch5 Windows behavior: launch first user-configured app or URL suggested X keysym: XF86Launch1 keycap: "2" evemu-record: EV_KEY / KEY_F15 X keycode: 193 X keysym: XF86Launch6 Windows behavior: launch second user-configured app or URL suggested X keysym: XF86Launch2 keycap: "3" evemu-record: EV_KEY / KEY_F16 X keycode: 194 X keysym: XF86Launch7 Windows behavior: launch third user-configured app or URL suggested X keysym: XF86Launch3 keycap: camera evemu-record: EV_KEY / KEY_IMAGES X keycode: none X keysym: none Windows behavior: opens Pictures folder suggested X keysym: XF86Pictures keycap: magnifying glass surrounding "+" sign evemu-record: EV_KEY / KEY_ZOOMIN X keycode: none X keysym: none Windows behavior: zooms display in suggested X keysym: XF86ZoomIn keycap: magnifying glass surrounding "-" sign evemu-record: EV_KEY / KEY_ZOOMOUT X keycode: none X keysym: none Windows behavior: zooms display out suggested X keysym: XF86ZoomOut keycap: letters "ABC" with check mark below evemu-record: EV_KEY / KEY_SPELLCHECK X keycode: none X keysym: none Windows behavior: spell-check current document suggested X keysym: XF86Spell This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This problem still manifests under Fedora 26. The remaining problematic keys are unchanged from those listed in comment #28. (In reply to Ben Liblit from comment #28) > evemu-record: EV_KEY / KEY_IMAGES > evemu-record: EV_KEY / KEY_ZOOMIN > evemu-record: EV_KEY / KEY_ZOOMOUT > evemu-record: EV_KEY / KEY_SPELLCHECK all this are keycodes > 255 and *cannot* be routed under X. This is only fixable with wayland where we have 32-bit keycodes. but there the codes are handled by the compositor and libxkbcommon, so you'd be better off filing a bug against gnome-shell to handle those. As for the server, these are unfixable. Rather than dragging the bug along another couple of releases, I'm closing this one now, sorry. |
Created attachment 331514 [details] list of problematic keys and suggested bindings New Note 3 The Microsoft Wireless Desktop 7000 is a wireless mouse and keyboard bundle with a single 2.4GHz transceiver. The keyboard is labeled "Microsoft Wireless Keyboard 7000". This keyboard has numerous special-function keys. Several of these produce either incorrect keysyms under X or no keypress events at all. (Happily, most work just fine.) I am using a non-empty "xorg.conf" because of special video driver configuration requirements. There are zero InputDevice sections/directives, though. So for input configuration, X should be using its default HAL-supported auto-discovery facilities. For that reason I'm filing this as an evdev bug. It might need to be moved elsewhere if something else is at fault, but I'm not really sure how to diagnose that. I used "xev" to check the bindings for each special key. I will attach a document listing all keys that work incorrectly, along with suggested corrections. In cases where the keycode is given as "none", then pressing the key generates no visible event whatsoever in "xev". In every one of those cases, "lshal -m" also reports no BUttonPressed event.