Bug 485010 - missing/incorrect keysyms with Microsoft Wireless Keyboard 7000
missing/incorrect keysyms with Microsoft Wireless Keyboard 7000
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
26
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
http://www.microsoft.com/hardware/mou...
: Reopened, Triaged
Depends On: 904848
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-10 23:49 EST by Ben Liblit
Modified: 2017-09-04 23:41 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-09-04 23:41:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
list of problematic keys and suggested bindings (1.50 KB, text/plain)
2009-02-10 23:49 EST, Ben Liblit
no flags Details
output of "xkbcomp -xkb :0 -" (44.02 KB, text/plain)
2009-02-12 02:19 EST, Ben Liblit
no flags Details
output of "xev" (1.59 KB, text/plain)
2009-02-12 02:21 EST, Ben Liblit
no flags Details
output of "evtest /dev/input/event3" (7.23 KB, text/plain)
2010-05-28 19:29 EDT, Ben Liblit
no flags Details

  None (edit)
Description Ben Liblit 2009-02-10 23:49:54 EST
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.
Comment 1 Peter Hutterer 2009-02-12 01:48:33 EST
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.
Comment 2 Ben Liblit 2009-02-12 02:19:49 EST
Created attachment 331661 [details]
output of "xkbcomp -xkb :0 -"
Comment 3 Ben Liblit 2009-02-12 02:21:29 EST
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.
Comment 4 Peter Hutterer 2009-03-19 19:47:45 EDT
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.
Comment 5 Ben Liblit 2009-03-23 23:50:16 EDT
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.
Comment 6 steve 2009-06-30 18:32:52 EDT
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 7 Ben Liblit 2009-06-30 18:49:37 EDT
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.
Comment 8 steve 2009-06-30 19:04:47 EDT
will do, thanks for the fast response.
Comment 9 Bug Zapper 2009-11-18 06:05:07 EST
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
Comment 10 Bug Zapper 2010-04-27 08:56:04 EDT
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
Comment 11 Peter Hutterer 2010-04-27 21:20:42 EDT
Ben, please run evtest against the device file, then press the buttons and attach the evtest output here.
Comment 12 Ben Liblit 2010-05-28 19:29:25 EDT
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.
Comment 13 Bug Zapper 2010-11-04 07:31:27 EDT
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
Comment 14 Ben Liblit 2010-11-07 13:31:42 EST
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
Comment 15 Peter Hutterer 2012-01-15 20:06:30 EST
(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.
Comment 16 Ben Liblit 2012-01-20 19:32:01 EST
> 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.
Comment 17 Fedora End Of Life 2013-01-16 20:19:32 EST
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
Comment 18 Ben Liblit 2013-01-21 17:08:06 EST
Problem still manifests under Fedora 18.
Comment 19 Peter Hutterer 2013-01-25 20:25:53 EST
(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.
Comment 20 Ben Liblit 2013-01-27 16:28:02 EST
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.
Comment 21 Fedora End Of Life 2013-12-21 09:51:24 EST
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.
Comment 22 Ben Liblit 2013-12-23 21:21:34 EST
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.
Comment 23 Fedora End Of Life 2015-05-29 04:35:42 EDT
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.
Comment 24 Ben Liblit 2015-06-01 12:15:51 EDT
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
Comment 25 Ben Liblit 2015-06-01 12:18:02 EDT
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
Comment 26 Peter Hutterer 2015-06-02 20:45:02 EDT
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.
Comment 27 Fedora End Of Life 2016-07-19 16:49:31 EDT
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.
Comment 28 Ben Liblit 2016-07-27 14:16:01 EDT
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
Comment 29 Fedora End Of Life 2017-07-25 14:27:57 EDT
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.
Comment 30 Ben Liblit 2017-07-25 18:03:55 EDT
This problem still manifests under Fedora 26.  The remaining problematic keys are unchanged from those listed in comment #28.
Comment 31 Peter Hutterer 2017-09-04 23:41:09 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.