Bug 1227521

Summary: Keyboard layout switching isn't working on XWayland
Product: [openSUSE] openSUSE Distribution Reporter: Oleg Kalugin <i>
Component: X.OrgAssignee: Gfx Bugs <gfx-bugs>
Status: RESOLVED DUPLICATE QA Contact: Gfx Bugs <gfx-bugs>
Severity: Major    
Priority: P3 - Medium CC: lubos.kocman, r.neumaier
Version: Leap 15.6   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Oleg Kalugin 2024-07-08 14:27:47 UTC
After update to Leap 15.6 keyboard layout switching on XWayland applications isn't working. 

This bug is related to old xkbcomp version (1.4.1), which hasn't been updated since the release of Leap 15.0 (25.05.2018).
Comment 1 Stefan Dirsch 2024-07-08 14:57:06 UTC
This was already reported and fixed for SP6. Unfortunately I can't find the bug  ticket any longer. I've applied this one-and-only patch, which we figured out vi git bisect in the end.

commit 5bc2849273a224a2df593b7e8df31f0bde666482
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jun 7 11:25:01 2018 +1000

    Ignore xkb_keycodes.maximum of > 255
    
    Continuation from 7fdfabd75 "keycodes: Ignore high keycodes"
    
    A keymap with a key > 255 will have a xkb_keycodes.maximum of that keycode.
    Let's not throw a fatal error on that, just crop it back to the maximum of
    255. This doesn't set the "high_keycode_warned" on purpose so we get this for
    the first key that actually matters.
    
    Reproducible with xkeyboard-config 2.24 which has a maximum of 374.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1587998
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Daniel Stone <daniel@fooishbar.org>
Comment 3 Oleg Kalugin 2024-07-08 15:19:29 UTC
(In reply to Stefan Dirsch from comment #1)
> This was already reported and fixed for SP6. Unfortunately I can't find the
> bug  ticket any longer. I've applied this one-and-only patch, which we
> figured out vi git bisect in the end.
> 
> commit 5bc2849273a224a2df593b7e8df31f0bde666482
> Author: Peter Hutterer <peter.hutterer@who-t.net>
> Date:   Thu Jun 7 11:25:01 2018 +1000
> 
>     Ignore xkb_keycodes.maximum of > 255
>     
>     Continuation from 7fdfabd75 "keycodes: Ignore high keycodes"
>     
>     A keymap with a key > 255 will have a xkb_keycodes.maximum of that
> keycode.
>     Let's not throw a fatal error on that, just crop it back to the maximum
> of
>     255. This doesn't set the "high_keycode_warned" on purpose so we get
> this for
>     the first key that actually matters.
>     
>     Reproducible with xkeyboard-config 2.24 which has a maximum of 374.
>     
>     https://bugzilla.redhat.com/show_bug.cgi?id=1587998
>     
>     Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
>     Reviewed-by: Daniel Stone <daniel@fooishbar.org>

But it wasn't fixed for Leap, where this bug also exists. So, i created report for leap 15.6
Comment 4 Stefan Dirsch 2024-07-08 15:30:08 UTC
Fixed in the sense of a fixed package submitted. This doesn't mean it would have already been released as an update.
Comment 5 Stefan Dirsch 2024-07-08 15:38:22 UTC
Found it.

*** This bug has been marked as a duplicate of bug 1219505 ***
Comment 6 René Neumaier 2024-07-09 20:55:04 UTC
Hmm...
This bug was reported before the release of Leap 15.6, was fixed by S. Dirsch on June 6, and it still hasn't been accepted while the EOD countdown for 15.5 has started? No offense, but I'm a bit confused. I can't imagine that only we are so dependent on this.

In our case, this is a very big stumbling block when migrating from 15.5 to 15.6. A bit more than 100 managed computers would be affected by this issue, as a seamless change of keyboard layout is mandatory for our international users in a university.


@Stefan Dirsch
Do you have any idea when your patch will be accepted/rolled out?
I can apply and deploy your patch to our local repository, but I've seen that more people are having problems with this bug.
Comment 7 Stefan Dirsch 2024-07-09 22:52:28 UTC
Not exactly. I submitted the fix on Jun 18. It was checked in and now is in our QA Queue. I can't tell you when it will be released.
Comment 8 René Neumaier 2024-07-10 06:23:02 UTC
Ok, but thanks for your work and your feedback! :)