<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Spontaneous keyboard layout switching after upgrade to XWayland 1.18.0" href="https://bugs.freedesktop.org/show_bug.cgi?id=93237#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Spontaneous keyboard layout switching after upgrade to XWayland 1.18.0" href="https://bugs.freedesktop.org/show_bug.cgi?id=93237">bug 93237</a> from <a class="email" href="mailto:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>So I found out what caused the issues on my end, but I cannot verify it is what is causing issues for others. So in my case, as described in <a href="show_bug.cgi?id=93237#c4">comment 4</a>, the layout switch was only valid for one key. After some digging, the reason was a bag X11 client; in my case a nested mutter instance (i.e. running mutter as a nested Wayland compositor on top of X11) trying to have a say in the XkbState. Mutter normally does this, being the window manager, but when running nested, it's not a good idea to mess with the host X11 servers xkb state. So, if anyone still is hitting this, this is a way to find out what client is screwing up the state (assuming its the same type of issue). 1. Set the keyboard layout you want and focus an X11 client 2. From another computer, attach gdb to the Xwayland process 3. Add a break point on the 'event_get_corestate' function 4. Press some key to trigger some X11 key event 5. When the breakpoint hits, add a hardware watch point on the value the '&kbd->key->xkbInfo->state.locked_group' pointer points at (e.g. "watch *(unsigned char *)0x123456" where the above pointer is 0x123456.) 6. Disable the breakpoint on 'event_get_corestate'. 7. Continue gdb 8. Reproduce the issue 9. Check that gdb have stopped, hopefully in ProcXkbLatchLockState() 10. Inspect the client mask: printf "0x%x\n", client->clientAsMask 11. Look up what client it is by comparing the mask with the windows listed by xwininfo -root -tree. For example if the client mask above was 0x1600000, try "xwininfo -root -tree | grep 0x16". Note, there might be a better way to intercept and examine client protocol traffic that I don't know about. The key point is to find what client tries to mess with the xkb state.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>