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: https://gitlab.gnome.org/GNOME/gsettings-desktop-schemas/commit/751e44568c73f80097e57ff83952f249468b4e9f 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. gsettings-desktop-schemas-3.32.0-1.fc30.x86_64 How reproducible: always 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.
Interestingly, the commit you mentioned says: "The key will only be usable on a wayland session."
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).
Yet another pains... https://bugzilla.redhat.com/show_bug.cgi?id=1705429#c2
*** Bug 1705429 has been marked as a duplicate of this bug. ***
Peter, could you please take a look at this? I'm not sure if this is filed against the right component. Thanks!
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 :)
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.
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.
Any hope to get this patch to Fedora 30 updates?
FEDORA-2019-48cc1b129e has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-48cc1b129e
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
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.
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 bug. Thank you for reporting this bug and we are sorry it could not be fixed.