Interestingly the switch of layout is respected in gedit but not in google-chrome.

So the only place whthe

It does seem like they keyboard layout shows null in case of "cs" layout. See the attached video.

Created attachment 872401 [details]
input switching working for gedit but not for chromium and google-chrome-stable

On this video, I'm trying to demonstrate that input switching works for gedit, but is completely ignored for google-chrome-stable (from google) and chromium (from Leap 15.6 oss repo).

Interestingly the show-keyboard-layout dialog shows layout "null" in case of cs layout.

Also as I type in chrome/chromium the text input is "slow" and sometimes flickering, which can be also seen on the video.

(In reply to Lubos Kocman from comment #3)
> Created attachment 872401 [details]
> input switching working for gedit but not for chromium and
> google-chrome-stable
> 
> On this video, I'm trying to demonstrate that input switching works for
> gedit, but is completely ignored for google-chrome-stable (from google) and
> chromium (from Leap 15.6 oss repo).
> 
> Interestingly the show-keyboard-layout dialog shows layout "null" in case of
> cs layout.

In this case, if the input method works normally in the firefox and other aplications?

Are you using the Ozone Wayland backend of Chrome? It is known that input method does not work with that, you could check it by visit chrome://gpu and check Ozone platform.

(In reply to Alynx Zhou from comment #6)
> Are you using the Ozone Wayland backend of Chrome? It is known that 

Sorry, does google announce that? Could you paste any reference link here?
Thank you!

(In reply to Cliff Zhao from comment #7)
> (In reply to Alynx Zhou from comment #6)
> > Are you using the Ozone Wayland backend of Chrome? It is known that 
> 
> Sorry, does google announce that? Could you paste any reference link here?
> Thank you!

https://bugs.chromium.org/p/chromium/issues/detail?id=1039161

They don't have text-input-v3 support I think.

(In reply to Alynx Zhou from comment #8)
> (In reply to Cliff Zhao from comment #7)
> > (In reply to Alynx Zhou from comment #6)
> > > Are you using the Ozone Wayland backend of Chrome? It is known that 
> > 
> > Sorry, does google announce that? Could you paste any reference link here?
> > Thank you!
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=1039161
> 
> They don't have text-input-v3 support I think.
Good.But Chrome default use x11 but not wayland in the Ozone platform.

Created attachment 872491 [details]
chrome://gpu from google-chrome-stable

Hello here's the requested info from chrome://gpu.

Also the chrome literally "blinks/flashes" as I type. Other apps don't do that Not sure if it's related or worth a separate bug.

All works no flashing, and also correct input methods, if I use X11 instead of wayland.

(In reply to Lubos Kocman from comment #10)
> Created attachment 872491 [details]
> chrome://gpu from google-chrome-stable
> 
> Hello here's the requested info from chrome://gpu.
> 
> Also the chrome literally "blinks/flashes" as I type. Other apps don't do
> that Not sure if it's related or worth a separate bug.

I also get blinks with Chrome/Xwayland/NVIDIA, it could be https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317, though I don't think it blinks on KDE Plasma, I also opened an issue for GNOME: https://gitlab.gnome.org/GNOME/mutter/-/issues/3241.

However you are using Xwayland and input method should work with it...

Alynx, shall I create a separate bug for blinking in Chrome/Wayland and keep it separate from this input methods bug?

(In reply to Lubos Kocman from comment #13)
> Alynx, shall I create a separate bug for blinking in Chrome/Wayland and keep
> it separate from this input methods bug?

Yes, I think so, and I think a workaround is not put Chrome full screen, it will still blink, but less frequently.

Reported as Bug #1219718

(In reply to Lubos Kocman from comment #10)
> Created attachment 872491 [details]
> chrome://gpu from google-chrome-stable
> 
> Hello here's the requested info from chrome://gpu.
> 
...
From Lubos's attachment, I saw that the Ozone section is x11. Based on the clues we collected so far, this bug is not related to Google's bug which was mentioned previously. In the meantime, The input(iBus) works well in the gedit, even we don't get any feedback from other applications, I consider the iBus work well.
In my humble opinion, this bug needs the Wayland or Chrome maintainer to investigate further. if there have any questions related to the iBus, feel free to contact me, I'm glad to support.

To clarify:
(In reply to Lubos Kocman from comment #0)
> 
> Clicking on show keyboard layout does not seem to do anything so perhaps the
> service/application is crashing.
 
In this bug, this problem doesn't need to be fixed, This "show keyboard layout" is an individual program, and it does not affect whether the input method(iBus)works or if Chrome works. The user also can launch it when uninstalling the iBus and Chrome. like in a terminal :~> gkbd-keyboard-display -l cz
If anybody cares about it, open a new bug.
Thank you!

(In reply to Cliff Zhao from comment #17)
> To clarify:
> (In reply to Lubos Kocman from comment #0)
> > 
> > Clicking on show keyboard layout does not seem to do anything so perhaps the
> > service/application is crashing.
>  
> In this bug, this problem doesn't need to be fixed, This "show keyboard
> layout" is an individual program, and it does not affect whether the input
> method(iBus)works or if Chrome works. The user also can launch it when
> uninstalling the iBus and Chrome. like in a terminal :~>
> gkbd-keyboard-display -l cz
> If anybody cares about it, open a new bug.
> Thank you!

Reported as a minor severity bug 1220208

(In reply to Lubos Kocman from comment #18)
> (In reply to Cliff Zhao from comment #17)
> > To clarify:
...
> 
> Reported as a minor severity bug 1220208
Thank you.

Hi Alynx:
Could you please take a look if this is your bug? if yes, please pick it up; if not please feedback. I checked it is not related to input method, detailed analyze in previous comments. Since this bug has hanging nearly a month, the "Ozone" section which you mentioned before seems no relevant. I poked you just in case you forgot it. Thank you!

I'll also double check whether this is still an issue on Wayland (I have been recently using x11 so I can't say).

Ah yes confirming that the issue with input method switch still happens on Wayland. X11 works fine.

Just to confirm this issue is not specific to NVIDIA GPUs, the issue with keyboard layout switch happens with amdgpu driver too. 

The problem happens only in Wayland and only on chromium / chrome based apps, which includes all electron apps (e.g. slack from flathub etc, telegram, signal ... and all of these)

Noticed the following with a fresh install of Leap 15.6:

Regardless of keyboard settings in the system, chrome-based browsers (flatpak or native chromium) ignore the system keyboard and always default to an en keyboard.
Both with KDE and Gnome...

Switching to X11 makes the localized keyboard work, with KDE and Gnome. 
As such, seems to be an issue with Wayland only.

Workaround: Use Xorg where there is no issue, or have just a single keyboard layout in case you want to use Wayland.

Try this:

Fresh install of Leap 15.6 RC. Use English language and select an non-EN keyboard, German in my case.

* After installation, launch chromium, chrome or edge and notice the German keyboard is not working. *

All attempts at changing language, region, keyboard layout do not solve this issue. The keyboard works as expected everywhere we tested, except in chromium related products (flatpak or rpm did not matter). Also tried other keyboards with the same result, they do not work.


Again this is Wayland related as switching to X11 fixes it immediately.

(In reply to Oliver Albrecht from comment #23)
> Noticed the following with a fresh install of Leap 15.6:
> 
> Regardless of keyboard settings in the system, chrome-based browsers
> (flatpak or native chromium) ignore the system keyboard and always default
> to an en keyboard.
> Both with KDE and Gnome...

I noticed the same. Using Leap 15.6 RC (all the latest updates applied) with GNOME 45.3 and Chromium 122. Always when I reboot and open Chromium, it does not respect the keyboard layout. Other apps (such as Gedit or Firefox) respect the keyboard layout.

> Switching to X11 makes the localized keyboard work, with KDE and Gnome. 
> As such, seems to be an issue with Wayland only.

I didn't try that. But what works for me is: just open YaST System Keyboard Layout, select any other random keyboard layout, and right after select the correct keyboard layout, test and click Accept. Back to Chromium (no need to close and open again) now it is possible to type as usual.

(In reply to Lubos Kocman from comment #22)
> Just to confirm this issue is not specific to NVIDIA GPUs, the issue with
> keyboard layout switch happens with amdgpu driver too.

In fact, I'm using an Intel integrated graphics card and it happens to me too.

(In reply to Lubos Kocman from comment #24)
> Workaround: Use Xorg where there is no issue, or have just a single keyboard
> layout in case you want to use Wayland.

I'll try Xorg. But right now I'm using Wayland, I have just a single keyboard layout - Portuguese (Brazil) - and I'm affected by the bug.

Hi Alynx, I know you were closely debugging recent wayland features, can you please also help to check this one? Thanks!

If you get no input method in chromium under Wayland:

Chromium only has text-input-v1, while mutter only has text-input-v3, there currently is no way to make them work without any changes. If you need to use them now, I suggest just run chromium with Xwayland, which is what I am using.

This could be solved by either 1. mutter supports text-input-v1, just what kwin and hyprland did just for chromium/electron (I am trying to do this, it is not easy and I don't know whether upstream will accept it), 2. chromium supports text-input-v3, just like nearly every other wayland apps (but their developer insists text-input-v3 misses some feature they need, so until text-input-v3 has what they need they won't support it).

If you mean you cannot see the keyboard layout, it is another bug: https://bugzilla.suse.com/show_bug.cgi?id=1220208, and the SR has been merged.

I am trying to implement text-input-v1, but before that I suggest to use Xwayland for chromium.

To summarize the issue: when a user installs Leap 15.6 with a localized keyboard chosen (or changes to a localized keyboard on an installed system), chromium based browsers instead always use the en keyboard layout and ignore the system keyboard setting.

There seem to be several workarounds for this, although of course a localized keyboard needs to work out of the box for any distribution - without workarounds.

Workaround #1

Chromium based browsers use the X11 ozone backend by default, unless configured otherwise.
While this works on tumbleweed with wayland and provides a localized keyboard, on Leap 15.6 it seems to be related to this issue.

The workaround is to go to chrome://flags and "Preferred Ozone platform", here you can switch to "Auto"or "Wayland" and that provides the correct layout.

Edge does not support this flag, but you can use a command line switch like this to start Edge "--ozone-platform=wayland"

The same command line switch also works with other browsers, and also with flatpaks:

chromium --ozone-platform=wayland
flatpak run com.google.Chrome --ozone-platform=wayland
flatpak run com.microsoft.Edge --ozone-platform=wayland
  
Workaround #2

Switch to X11, the localized keyboard issue is gone

I got misleading by the title and chromium. This is not text-input-v1 related.

@Oliver To be clear, you mean when chromium running with Xwayland (not Wayland, you can run `xlsclients` and see whether chromium is in the list), layout switching is not working?

Keyboard layout switch should work no matter X11/Xwayland/Wayland, that is strange.

@Alynx Zhou 

To clarify, non-EN keyboards do not work here at all in Chrome, Chromium etc. with a default Leap 15.6 installation (which uses Wayland, not X11).

Aside from a standard physical installation, I made two additional installs of Leap in qemu, one with KDE and one with Gnome, and selected EN as system language with the German keyboard being localized and the ONLY keyboard selected.

In all tests the DE Keyboard works fine everywhere, aside from Chrome/Chromium and other related apps like Edge. It does not matter whether they are native rpm or flatpak, the keyboard defaults back to EN instead of DE.
Same with other localized keyboards I tested.

The workarounds in comment #30 apply.

So for all practical purposes this means, a user installing Leap 15.6 RC will be unable to use a localized keyboard in these apps.

Maybe someone else could verify this behavior to ensure it's just not something I am doing that triggers this.

@Alynx Zhou did you see what I wrote about YaST in comment #26? What could explain that change works on the fly?

I just realized that VSCodium is also affected by this bug as well as Chrome/Chromium.

Currently, I'm using VSCodium 1.89.1.

(In reply to Projeto Linux Kamarada from comment #33)
> @Alynx Zhou did you see what I wrote about YaST in comment #26? What could
> explain that change works on the fly?

Can confirm, setting the keyboard in Yast to something else and back fixes the layout until the next reboot.

Further testing revealed, setxkbmap can do the same as Yast:

"setxkbmap -layout de" sets the localization correctly for the session too.

Of course the change doesn't persist, after a reboot it needs to be done again.
It could probably be put into .profile or so, but the root cause remains.

The entire keyboard- and language-related configuration looks fine to me, especially /etc/X11/xorg.conf.d/00-keyboard.conf is correct.

I can confirm the bug for KDE Plasma with Wayland Session. It also affects other XWayland apps such as SoftMaker Office.

Hello 
we expect that by the time of GA (June 12th), there will be already a released uptate in the sle-update repository for Leap 15.6. So fix will be available with 15.6 GA.

The maintenance update priorization request was already made.

Thank you for your undestanding!

(In reply to Cruiz from comment #37)
> I can confirm the bug for KDE Plasma with Wayland Session. It also affects
> other XWayland apps such as SoftMaker Office.

Same, also affects JetBrains IDEs, ElectronJS Apps

*** Bug 1225612 has been marked as a duplicate of this bug. ***

(In reply to Cruiz from comment #37)
> I can confirm the bug for KDE Plasma with Wayland Session. It also affects
> other XWayland apps such as SoftMaker Office.

Then I am wondering it is a XWayland bug, not GNOME bug.

SUSE-RU-2024:1904-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1219505
Maintenance Incident: [SUSE:Maintenance:34046](https://smelt.suse.de/incident/34046/)
Sources used:
openSUSE Leap 15.6 (src):
 mutter-45.3-150600.5.3.1
Desktop Applications Module 15-SP6 (src):
 mutter-45.3-150600.5.3.1

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.

XWayland 24.1 in factory does not have this bug, we need XWayland maintainers to help find the fix and backport it.

gitlab.freedesktop.org is currently down due to maintenance. :-(

Could this be related to Xwayland adding Explicit Sync with 24.1 release?

  https://www.phoronix.com/news/XWayland-24.1-Released

xwayland 24 releases

24.1.0 RC1 https://lists.x.org/archives/xorg-announce/2024-April/003510.html
24.1.0 RC2 https://lists.x.org/archives/xorg-announce/2024-May/003513.html
24,1,0 GM  https://lists.x.org/archives/xorg-announce/2024-May/003515.html

xwayland >= 23.2.5 releases

23.2.6 https://lists.x.org/archives/xorg-announce/2024-April/003498.html
23.2.6 https://lists.x.org/archives/xorg-announce/2024-April/003503.html
23.2.7 https://lists.x.org/archives/xorg-announce/2024-May/003514.html

In case it's not related to Explicit Sync it might have already be fixed in 23.2.7. In case anybody would be able and willing to test it I can build a xwayland 23.27 package for testing.

Explicit sync sounds not related with keyboard layout, but I think 23.2.7 is worth trying.

Fine. @Alynx Please give it a try. Thanks!

https://build.suse.de/package/show/home:sndirsch:branches:SUSE:SLE-15-SP6:Update/xwayland

(In reply to Stefan Dirsch from comment #47)
> Fine. @Alynx Please give it a try. Thanks!
> 
> https://build.suse.de/package/show/home:sndirsch:branches:SUSE:SLE-15-SP6:
> Update/xwayland

I just tested this and unfortunately it does not fix this bug. Maybe the fix is in 24.1

There are a bunch of xkb changes in 24.1, but none of them looks related. First I'll do a 24.1 RC1 build, then RC2 and 24.1 final (if needed), then we can git bisect the issue. About 7 bisect steps needed.

Please now try 24.0.99.901. Again same location.

https://build.suse.de/package/show/home:sndirsch:branches:SUSE:SLE-15-SP6:Update/xwayland

RPM changelog:

-------------------------------------------------------------------
Wed Jun  5 09:41:52 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- Update to 24.0.99.901 for testing bsc#1219505

BTW, this needed updates of a bunch of proto packages. :-(

(In reply to Stefan Dirsch from comment #50)
> Please now try 24.0.99.901. Again same location.
> 
> https://build.suse.de/package/show/home:sndirsch:branches:SUSE:SLE-15-SP6:
> Update/xwayland
> 
> RPM changelog:
> 
> -------------------------------------------------------------------
> Wed Jun  5 09:41:52 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>
> 
> - Update to 24.0.99.901 for testing bsc#1219505
> 
> BTW, this needed updates of a bunch of proto packages. :-(

This still not works, strange.

Thanks. Next try (same location)

-------------------------------------------------------------------
Thu Jun  6 09:11:59 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- Update to 24.0.99.902 for testing bsc#1219505 

(currently rebuilding; don't download too early and check RPM changelog before testing)

(In reply to Stefan Dirsch from comment #52)
> Thanks. Next try (same location)
> 
> -------------------------------------------------------------------
> Thu Jun  6 09:11:59 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>
> 
> - Update to 24.0.99.902 for testing bsc#1219505 
> 
> (currently rebuilding; don't download too early and check RPM changelog
> before testing)

I tried 902, it still not fix this bug, I am wondering maybe this bug is also affected by other packages?

Thanks. Next try (same location)

-------------------------------------------------------------------
Fri Jun  7 08:17:34 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- Update to 24.1.0 for testing bsc#1219505 

(currently rebuilding; don't download too early and check RPM changelog before testing)

(In reply to Alynx Zhou from comment #53)
> I tried 902, it still not fix this bug, I am wondering maybe this bug is
> also affected by other packages?

First let's try 24.1.0.

(In reply to Stefan Dirsch from comment #54)
> First let's try 24.1.0.

Still not works.

Ok. Thanks!

I suggest to try first with simple X programs. Start xterm. Inside then run

  setxkbmap -layout  us
  setxkbmap -layout cs

Does this switch the keyboard layouts? Then try this one:

  setxkbmap -layout "us,cs" -option grp:alt_shift_toggle

Can you now switch between these keyboard layouts with Alt+Shift?

Leap 15.6 was released today and I still can't get a localized keyboard working with the default install for chromium/chrome/ozone apps.

That makes me wonder if I'm doing something wrong (or the other people here testing with the same result) or if nobody is actually running Leap 15.6 or those apps?

Maybe it would make sense for someone else to test the following, and if it applies to you as well, we could try to rename the bug for more clarity or to possibly open a new one that is more specific?

ISSUE: No working localized keyboard in chromium/chrome/zone apps

REQUIRED : Wayland (is installed per default, issue does not apply with X11)

STEPS TO REPRODUCE: Install Leap 15.6, e.g. with KDE or GNOME, choose a localized keyboard (in my case DE) and the language of your choice (EN-US in my case).
Use chromium (flatpak or os) and realize the keyboard layout is not DE but instead  EN-US in those apps 

WORKAROUND: setxkbmap de fixes it for the running session. Manually setting Ozone to Wayland in chrome works as well

Maybe it's better to rename this bug, as it affects all XWayland apps on all Desktop Environments?

First we need to figure out what's the issue here. Seems things like setxkbmap are working. But I need more feedback by Lubos first. See comment#57. My current guess is that there is an issue with the input method system (ibus or whatever is used on GNOME) when using X applications.

(In reply to Stefan Dirsch from comment #60)
> First we need to figure out what's the issue here. Seems things like
> setxkbmap are working. But I need more feedback by Lubos first. See
> comment#57. My current guess is that there is an issue with the input method
> system (ibus or whatever is used on GNOME) when using X applications.

Is KDE also using IBus?

(In reply to Oleg Kalugin from comment #61)
> (In reply to Stefan Dirsch from comment #60)
> > First we need to figure out what's the issue here. Seems things like
> > setxkbmap are working. But I need more feedback by Lubos first. See
> > comment#57. My current guess is that there is an issue with the input method
> > system (ibus or whatever is used on GNOME) when using X applications.
> 
> Is KDE also using IBus?

I don't know, but the bug was reported against GNOME. Also there is no KDE on SLED.

The first comments clearly mentions this is a Leap 15.6 issue. Possibly this was opened against the wrong OS and maybe that is more of a reason to move or reopen it elsewhere maybe?

I've tried to summarize the issue several times, in comment #58 for example.
Also it seems like that description matches the root cause of what the OP was describing. 

Can someone possibly move this to Opensuse Leap distribution then since it now happens in the current Leap 15.6 release version?

Also please note that this is possibly XWayland related and seems to be unrelated to the window manager. Also seems to be unrelated to ibus since ibus is (for all I can tell) not used with leap 15.6.

(In reply to Stefan Dirsch from comment #62)
> (In reply to Oleg Kalugin from comment #61)
> > (In reply to Stefan Dirsch from comment #60)
> > > First we need to figure out what's the issue here. Seems things like
> > > setxkbmap are working. But I need more feedback by Lubos first. See
> > > comment#57. My current guess is that there is an issue with the input method
> > > system (ibus or whatever is used on GNOME) when using X applications.
> > 
> > Is KDE also using IBus?
> 
> I don't know, but the bug was reported against GNOME. Also there is no KDE
> on SLED.

There is no KDE on SLED, but there is on Leap 15.6, and there this bug exists in both GNOME and KDE

I managed to find the cause of this bug. It is xkbcomp-1.4.1-1.9.x86_64 package.
After installing a newer version this bug was fixed.

https://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Leap_15.6/x86_64/xkbcomp-1.4.7-lp156.43.2.x86_64.rpm

(In reply to Oleg Kalugin from comment #65)
> I managed to find the cause of this bug. It is xkbcomp-1.4.1-1.9.x86_64
> package.
> After installing a newer version this bug was fixed.
> 
> https://download.opensuse.org/repositories/X11:/XOrg/openSUSE_Leap_15.6/
> x86_64/xkbcomp-1.4.7-lp156.43.2.x86_64.rpm

Ok. If this holds true for everyone affected we could bisect that issue. About 6 steps.

I can confirm that I can switch keyboard layouts under Wayland/Chromium/Chrome with 
/home/lkocman/Downloads/xkbcomp-1.4.7-lp156.43.2.x86_64.rpm

Ok. So let's bisect that.

First let's verify, whether a rebuild from 1.4.7 tag from git fixes this issue as well.

https://download.opensuse.org/repositories/home:/sndirsch:/branches:/SUSE:/SLE-15:/Update/standard/

Packages are still rebuilding.

https://build.opensuse.org/project/monitor/home:sndirsch:branches:SUSE:SLE-15:Update

Check RPM changelog before testing.

-------------------------------------------------------------------
Mon Jun 17 11:04:37 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- 1.4.7 testbuild for bisecting boo#1219505

Also I think you need to kill Xwayland before you can test again. I believe xkbcomp is executed by Xwayland during startup.

(In reply to Stefan Dirsch from comment #68)

> First let's verify, whether a rebuild from 1.4.7 tag from git fixes this
> issue as well.
> 
> https://download.opensuse.org/repositories/home:/sndirsch:/branches:/SUSE:/
> SLE-15:/Update/standard/

Awesome find by Oleg Kalugin!

xkbcomp-1.4.7-150600.3.1.x86_64.rpm from the above directory (modified 1:47pm) appears to fix the problem as well

Thanks for testing, Oliver. Now next step.

-------------------------------------------------------------------
Mon Jun 17 11:55:13 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- [634f60a9b25b5d03c78e90574adce3e38f378333] testbuild for bisecting
  boo#1219505
  * gitlab CI: stop requiring Signed-off-by in commits

I raised version number now to artificial number 1.5.0. 

RPM changelog. Packages are still rebuilding

-------------------------------------------------------------------
Mon Jun 17 11:55:13 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- [634f60a9b25b5d03c78e90574adce3e38f378333] testbuild for bisecting
  boo#1219505
  * gitlab CI: stop requiring Signed-off-by in commits

(In reply to Stefan Dirsch from comment #70)

xkbcomp-1.5.0-150600.4.1.x86_64.rpm (4:04pm) fixes it too

Thanks. Next step

-------------------------------------------------------------------
Mon Jun 17 14:49:04 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- [790b998647ec171133bf196a3d84c5153cd64840] testbuild for bisecting
  boo#1219505
  * xkbcomp 1.4.4

(In reply to Stefan Dirsch from comment #72)

> - [790b998647ec171133bf196a3d84c5153cd64840] testbuild for bisecting
>   boo#1219505
>   * xkbcomp 1.4.4


localhost:/home/oalbrecht # rpm --install --force xkbcomp-1.5.0-150600.5.1.x86_64.rpm 
warning: xkbcomp-1.5.0-150600.5.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 05bb77f2: NOKEY
localhost:/home/oalbrecht # xkbcomp -version
xkbcomp 1.4.4

This one works too (file written 4:54pm).

Thanks. Next step.

-------------------------------------------------------------------
Mon Jun 17 15:23:56 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- [ff0e59084d6b9f2e7085fc88ba68916150085afb] testbuild for bisecting
  boo#1219505
  * xkbcomp Fix missing support for "affect" and incorrect modifier
    handling for ISOLock

(In reply to Stefan Dirsch from comment #74)
> Thanks. Next step.
> 
> -------------------------------------------------------------------
> Mon Jun 17 15:23:56 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>
> 
> - [ff0e59084d6b9f2e7085fc88ba68916150085afb] testbuild for bisecting
>   boo#1219505
>   * xkbcomp Fix missing support for "affect" and incorrect modifier
>     handling for ISOLock

This one works again, xkbcomp-1.5.0-150600.6.1.x86_64.rpm (5:27pm).

Heading home from work now, will gladly test more in the morning.

Thanks. Next step.

-------------------------------------------------------------------
Mon Jun 17 15:42:13 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- [1fdbacbe34742328b2a95742982b6017f60a1342] testbuild for bisecting
  boo#1219505
  * Suppress high-keycode warnings at the default warning level

This one xkbcomp-1.5.0-150600.7.1.x86_64.rpm fixes it too

Thanks. And the winnner is:

https://bugzilla.suse.com/show_bug.cgi?id=1219505#c77

Please do me a favour and verify this.

1. Go back to original 1.4.1 RPM of Leap 15.6. Verify that the issue exists. 
2. Upgrade to the new build (again 1.4.1) with the RPM changelog:

-------------------------------------------------------------------
Tue Jun 18 09:18:18 UTC 2024 - Stefan Dirsch <sndirsch@suse.com>

- U_Ignore-xkb_keycodes.maximum-of-255.patch
  * fix keyboard layouts in XWayland applications when having
    several keyboard layouts enabled (boo#1219505)

(check with rpm --changelog -q xkbcomp | head -n 7)

3. Verify that the issue is fixed with that version (currently still rebuilding). It only contains one patch.

(In reply to Stefan Dirsch from comment #78)
> Thanks. And the winnner is:
> 
> https://bugzilla.suse.com/show_bug.cgi?id=1219505#c77

Wrong URL. :-(

https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/commit/5bc2849273a224a2df593b7e8df31f0bde666482

(In reply to Stefan Dirsch from comment #79)
> (In reply to Stefan Dirsch from comment #78)

Restored a virtual machine with the issue active (it hds the original/shipped xkbcomp-1.4.1-1.9.x86_64).

Next I installed your new xkbcomp-1.4.1-150600.9.1.x86_64.rpm (11:44am) which fixes the problem. as expected.

Afterwards I reverted back to the original xkbcomp to verify the issue reappears, which it does, then installed xkbcomp-1.4.1-150600.9.1.x86_64.rpm once again to double check it still works.

Great job tracking this down, thank you!

Thanks for verifying, that this patch fixes it.

Fix is submitted now. Closing therefore.

Many thanks to everyone who participated!

*** Bug 1222754 has been marked as a duplicate of this bug. ***

*** Bug 1227521 has been marked as a duplicate of this bug. ***

*** Bug 1227612 has been marked as a duplicate of this bug. ***

*** Bug 1227522 has been marked as a duplicate of this bug. ***

SUSE-RU-2024:2402-1: An update that has one fix can now be installed.

Category: recommended (moderate)
Bug References: 1219505
Maintenance Incident: [SUSE:Maintenance:34540](https://smelt.suse.de/incident/34540/)
Sources used:
openSUSE Leap 15.5 (src):
 xkbcomp-1.4.1-150000.3.3.2
openSUSE Leap 15.6 (src):
 xkbcomp-1.4.1-150000.3.3.2
Basesystem Module 15-SP5 (src):
 xkbcomp-1.4.1-150000.3.3.2
Basesystem Module 15-SP6 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Manager Proxy 4.3 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Manager Retail Branch Server 4.3 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Manager Server 4.3 (src):
 xkbcomp-1.4.1-150000.3.3.2
SUSE Enterprise Storage 7.1 (src):
 xkbcomp-1.4.1-150000.3.3.2

NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination.