Bug 1974983 - After upgrade xkeyboard-config to version 2.33-1.fc35 layout indicator stop react to layout switch by Ctrl-Shift key combination.
Summary: After upgrade xkeyboard-config to version 2.33-1.fc35 layout indicator stop r...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-shell
Version: 35
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Florian Müllner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-06-22 21:50 UTC by Mikhail
Modified: 2021-10-11 01:50 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
patch (16.52 KB, patch)
2021-10-09 18:52 UTC, Mikhail
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
freedesktop.org Gitlab xkeyboard-config/xkeyboard-config - issues 285 0 None opened After commit 2a0c538c518becc49aedd66dc21460418af1dcd8 stop working Ctrl+Shift in GNOME Wayland session for switching lay... 2021-10-09 19:03:20 UTC

Description Mikhail 2021-06-22 21:50:29 UTC
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

Comment 1 Filippe LeMarchand 2021-07-07 15:15:47 UTC
This also affects Fedora 34 with xkeyboard-config-2.33-1.fc34

Comment 2 Sergio Basto 2021-08-01 20:48:18 UTC
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

Comment 3 Ben Cotton 2021-08-10 13:08:29 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 35 development cycle.
Changing version to 35.

Comment 4 Mikhail 2021-10-09 18:14:34 UTC
(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

Comment 5 Mikhail 2021-10-09 18:52:53 UTC
Created attachment 1831267 [details]
patch

Comment 6 Mikhail 2021-10-09 18:54:26 UTC
I am checked my patch and I'm even more sure that I found the right bad commit.

Comment 7 Peter Hutterer 2021-10-11 01:50:51 UTC
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.


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