Bug 1697804 - Insert key stops working after switching layout in Gnome under Xorg
Summary: Insert key stops working after switching layout in Gnome under Xorg
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-server
Version: 30
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Hutterer
QA Contact: Fedora Extras Quality Assurance
: 1705429 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2019-04-09 07:00 UTC by Viktor Ashirov
Modified: 2020-05-26 17:39 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-05-26 17:39:02 UTC
Type: Bug

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
GNOME Gitlab GNOME mutter issues 511 None None None 2019-04-15 11:23:36 UTC

Description Viktor Ashirov 2019-04-09 07:00:14 UTC
Description of problem:
After upgrade to F30 I noticed that my Insert key stops working after switching layout. This happens only under Xorg.

I managed to reproduce it on a clean F29 VM by upgrading one component after another. I nailed it down to an upgrade from gsettings-desktop-schemas-3.28.1-2.fc29.x86_64 to gsettings-desktop-schemas-3.32.0-1.fc30.x86_64.

The offending change is this:

I made a local scratch build with this patch reverted and it fixed the problem.

Some observations: XF86Keyboard has keycode 374, Insert has 118. 374-256=118. An integer overflow somewhere in Xorg?

Version-Release number of selected component (if applicable):
I'm not sure if gsettings-desktop-schemas is the right component, but it's the one exposing the problem, so I'm filing against it.

How reproducible:

Steps to Reproduce:
1. On F29 upgrade to gsettings-desktop-schemas-3.32.0-1.fc30.x86_64
   dnf --releasever=30 update gsettings-desktop-schemas
2. Logout and login to Gnome on Xorg
3. Switch layout from en to any other layout using default shortcut Win+Space.

Actual results:
Insert key stops working

Output in xev, when key is pressed and released:

FocusOut event, serial 37, synthetic NO, window 0x2400001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x2400001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0  

Expected results:

KeyPress event, serial 34, synthetic NO, window 0x2400001,
    root 0x2b3, subw 0x0, time 157492, (83,547), root:(921,691),
    state 0x0, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x2400001,
    root 0x2b3, subw 0x0, time 157537, (83,547), root:(921,691),
    state 0x0, keycode 118 (keysym 0xff63, Insert), same_screen YES,
    XLookupString gives 0 bytes: 

Additional info:
Downgrading gsettings-desktop-schemas (or installing a package with the patch reverted) or changing the shortcut for changing layouts fixes the problem.

Comment 1 Hedayat Vatankhah 2019-04-15 11:23:37 UTC
Interestingly, the commit you mentioned says: "The key will only be usable on a wayland session."

Comment 2 Hedayat Vatankhah 2019-04-15 11:25:22 UTC
Yet another interesting comment in: https://bugs.freedesktop.org/show_bug.cgi?id=101521
which might be related to the overflow you guessed:

NB: XF86Keyboard is a relatively new keysym and therefore needs
recent protocol headers. Also KEY_KEYBOARD's keysym is > 255
and therefore needs a recent xkbcomp (as the new KEY_FAVORITES).

Comment 3 olegon.ru 2019-05-14 19:03:38 UTC
Yet another pains...

Comment 4 Viktor Ashirov 2019-05-14 20:02:49 UTC
*** Bug 1705429 has been marked as a duplicate of this bug. ***

Comment 5 Viktor Ashirov 2019-05-14 20:11:15 UTC
Peter, could you please take a look at this?
I'm not sure if this is filed against the right component. 


Comment 6 Peter Hutterer 2019-05-29 06:18:44 UTC
Looks like this is an X server problem. XI2 allows for 32-bit keycode and mutter eventually calls XIGrabKeycode() with 374. In the server's CreateGrab() that's clipped to a 8-bit int without any checks. The actual grab stored is thus for (keycode % 256) and that's where the insert confusion comes from. Thanks for tracking this down, this certainly made debugging it easier :)

Comment 7 Peter Hutterer 2019-05-29 06:33:53 UTC
There's a scratch build running here now: https://koji.fedoraproject.org/koji/taskinfo?taskID=35120898

Can you please test this one and let me know if you see any side-effects? Shouldn't be, but one never knows.

Comment 8 Viktor Ashirov 2019-05-29 10:45:05 UTC
Thank you, Peter!

I did a quick test and it seems to work fine. My Insert key works properly after switching layouts. And the other media keys on my ThinkPad T440s work too. AFAIK, I don't have any keys with keycode>255, so can't test that.

Comment 9 Alexander Bokovoy 2019-06-20 09:34:45 UTC
Any hope to get this patch to Fedora 30 updates?

Comment 10 Fedora Update System 2019-06-24 00:56:57 UTC
FEDORA-2019-48cc1b129e has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-48cc1b129e

Comment 11 Fedora Update System 2019-06-25 02:11:13 UTC
xorg-x11-server-1.20.5-2.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-48cc1b129e

Comment 12 Ben Cotton 2020-04-30 20:52:54 UTC
This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
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 '30'.

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 30 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 13 Ben Cotton 2020-05-26 17:39:02 UTC
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 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

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

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