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: rawhide
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: 2022-11-29 18:40 UTC (History)
18 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
GNOME Gitlab GNOME gnome-shell issues 5071 0 None None None 2022-02-14 07:48:00 UTC
freedesktop.org Gitlab xkeyboard-config xkeyboard-config issues 285 0 None closed After commit 2a0c538c518becc49aedd66dc21460418af1dcd8 stop working Ctrl+Shift in GNOME Wayland session for switching lay... 2022-02-14 07:48:35 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.

Comment 8 Pavel Lisý 2021-11-11 20:08:59 UTC
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')]

Comment 9 Jens Petersen 2022-11-28 06:30:47 UTC
Does this affect F36 and later?

Comment 10 Mikhail 2022-11-28 06:43:12 UTC
(In reply to Jens Petersen from comment #9)
> Does this affect F36 and later?

yes it still actual even on Rawhide

Comment 11 Ben Cotton 2022-11-29 16:59:00 UTC
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.


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