Description of problem: After upgrade xkeyboard-config to version 2.33-1.fc35 layout indicator stop react to layout switch by Ctrl-Shift key combination. The bug is affected only Wayland session and only non standard layout switch key combination. Last good version is 2.32-3.fc35
This also affects Fedora 34 with xkeyboard-config-2.33-1.fc34
my commit [1] on xkeyboard-config-2.33 , disable shift + numlock + 7 = 7 and make shift + Home works in my kde ... TBH I haven't test wayland sessions, I don't use wayland (yet) , kde with wayland still a little unstable for me. but this commit [1] should only affect shift + NumLock (modifiers = Shift+NumLock;) [1] https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/3b6c73c0da5469e1be47286dca591777c916fa93
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle. Changing version to 35.
(In reply to Sergio Basto from comment #2) > my commit [1] on xkeyboard-config-2.33 , disable shift + numlock + 7 = 7 and > make shift + Home works in my kde ... > TBH I haven't test wayland sessions, I don't use wayland (yet) , kde with > wayland still a little unstable for me. > but this commit [1] should only affect shift + NumLock (modifiers = > Shift+NumLock;) > > [1] > https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/ > 3b6c73c0da5469e1be47286dca591777c916fa93 You're wrong, the bad commit turned out to be completely different. $ git bisect log git bisect start # good: [fe277acfc4d344ea84c48f1215a5fa8c96674dfe] Release 2.32 git bisect good fe277acfc4d344ea84c48f1215a5fa8c96674dfe # bad: [ba00d1dd8674ff05bd2a9f43c1198eeabcd1db47] Release 2.33 git bisect bad ba00d1dd8674ff05bd2a9f43c1198eeabcd1db47 # bad: [3a880f047e5cface9ff77f4d59fd91369d19e6f4] rules: remove duplicate cm(mmuock) from base.extras.xml git bisect bad 3a880f047e5cface9ff77f4d59fd91369d19e6f4 # bad: [3ba2817afc93c2ae14744c0401d41315492144c8] space cannot be typed on us(hyena), us(miniguru) and us(yoda) git bisect bad 3ba2817afc93c2ae14744c0401d41315492144c8 # good: [5ca9f8aea2876fe6926fc27f564d36eaf5ca5c8d] rules: add a "custom" layout to the XML file git bisect good 5ca9f8aea2876fe6926fc27f564d36eaf5ca5c8d # bad: [7676bca9698042e01c41c8582b8641738c5d984d] gitlab CI: make sure we have the latest keysyms in libxkbcommon git bisect bad 7676bca9698042e01c41c8582b8641738c5d984d # bad: [b469c358d0a86352e9e176b255f4fa62644ed601] symbols/inet: replace some manual symbols with their autogenerated version git bisect bad b469c358d0a86352e9e176b255f4fa62644ed601 # bad: [2a0c538c518becc49aedd66dc21460418af1dcd8] gitlab CI: check for new XF86 keysyms in the xorgproto repo git bisect bad 2a0c538c518becc49aedd66dc21460418af1dcd8 # first bad commit: [2a0c538c518becc49aedd66dc21460418af1dcd8] gitlab CI: check for new XF86 keysyms in the xorgproto repo https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/2a0c538c518becc49aedd66dc21460418af1dcd8
Created attachment 1831267 [details] patch
I am checked my patch and I'm even more sure that I found the right bad commit.
Punting to GNOME Shell, at least initially because this seems to be a bug with the keyboard indicator. Copy/paste from my upstream comment in https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/285 > Looks like the culprit is this line: > > key <I592> { [ ISO_Next_Group ] }; // KEY_KBD_LAYOUT_NEXT > > Having said that, the actual layout switching still works correctly, so this seems to be a bug with the layout indicator > rather than the actual layout. I've played around a bit and it seems to only affect layout switches that > require modifier state, so anything that is shift+something, alt+something or ctrl+something. > My guess would be that we have two keys both using ISO_Next_Group and the layout indicator doesn't handle this > correctly in regards to modifier state. Either way, please file a bug against GNOME Shell, at least initially > until it's further narrowed down. > Reproducing in Wayland is easy enough, edit /usr/share/X11/xkb/symbols/inet, comment that line out, then > remove+add a layout in the GNOME control panel to force a keymap regeneration (or change some XKB option). > This reliably reproduces the issue, depending on whether that line is commented out or not. > Bug cannot be reproduced in X because the keycode is out of range for X, so that's expected.
I can confirm this bug with some more details. Problems appears on wayland session only. In X session it works correctly. Behaviour: No layout indicator changes at all. Keyboard switches: 1. keyboard is on "us" 2. I press both shifts keyboard switched to "cz" 3. I press both shifts keyboard still stayed to "cz" 4. I press both shifts keyboard switched to "us" I get the same schema on both laptops: us -- cz -- cz -- us -- cz -- cz -- us My setup: Fedora 35 upgraded by dnf from f34 or f33 (two laptops) $ rpm -q xkeyboard-config xkeyboard-config-2.33-2.fc35.noarch $ loginctl show-session 4 -p Type Type=wayland $ localectl System Locale: LANG=cs_CZ.UTF-8 VC Keymap: us X11 Layout: us,cz X11 Model: , X11 Variant: grp:shifts_toggle $ dconf read /org/gnome/desktop/input-sources/xkb-options ['grp_led:scroll', 'grp:shifts_toggle', 'lv3:ralt_switch'] $ dconf read /org/gnome/desktop/input-sources/per-window true $ dconf read /org/gnome/desktop/input-sources/mru-sources [('xkb', 'cz'), ('xkb', 'us')]
Does this affect F36 and later?
(In reply to Jens Petersen from comment #9) > Does this affect F36 and later? yes it still actual even on Rawhide
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. 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 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
This component is maintained by the GNOME project. Issues with it should be reported directly to GNOME at https://gitlab.gnome.org/GNOME/. This issue should only be kept open if it: 1. Relates to Fedora packaging or integration with other Fedora components 2. Is required for Fedora release processes, such as blocker bugs and freeze exceptions If this issue isn't needed for either of these two reasons, please: * create an issue with GNOME * add a link to the GNOME issue here * close this issue as CLOSED/UPSTREAM Thank you!