Are you setting those options with the setxkbmap tool? If so, that is not supported, and please set those options through your compositor (e.g. GNOME Tweak Tool or weston.ini).

No, i am setting these options using the method, recommended by the WM (weston.ini for Weston; XKB_* variables for Orbment). The setxkbmap tool was used in an attempt to narrow the problem down to the component responsible.

I'm probably affected by this too. I am not using setxkbmap, but gnome-control-center.

$ localectl
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: de-neo
      X11 Layout: de,de
     X11 Variant: neo,nodeadkeys
     X11 Options: grp:sclk_toggle

I also have been affected by something similar to this I think.

Though, what I've experienced is that the layout is switched back us-dvorak-alt-intl from svdvorak after entering one character. For example what I have seen has been:

1. Switch to svdvorak
 * switched to svdvorak *
2. Press å
 * å is entered *
 * silently switched to us-dvorak-alt-intl in xwayland *
3. Switch to svdvorak
 * switched to svdvorak *
4. Press ¨ (dead key)
5. Press o
 * ö is entered *
 * silently switched to us-dvorak-alt-intl in xwayland * (or after 4., I don't know, o is in the same place)

Settings and switching has been done using GNOME. I don't know how to reproduce this reliably, and it doesn't happen that often. IIRC sometimes I haven't even been able to switch to svdvorak for entering one letter.

$ localectl
   System Locale: LANG=en_US.UTF-8
                  LC_NUMERIC=en_DK.utf8
                  LC_TIME=en_DK.utf8
                  LC_MONETARY=en_DK.utf8
                  LC_PAPER=en_DK.utf8
                  LC_MEASUREMENT=en_DK.utf8
       VC Keymap: us-dvorak-alt-intl
      X11 Layout: us,se
     X11 Variant: dvorak-alt-intl,svdvorak

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 comment 4, 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.

Simon, is Jonas's comment helpful for you at all?

(In reply to Daniel Stone from comment #6)
> Simon, is Jonas's comment helpful for you at all?

To be honest, not very much. Firstly, the described process is too complicated for me to reproduce. Secondly, the general context of the bug i was experiencing was different; I was using a typical set of programs (Firefox, weston-terminal, LibreOffice) under the Weston compositor, so no weird window manager nesting for me. Thirdly, i have since given up on Wayland, for now, and switched back to X.Org, in an attempt to work around its problems and get some useful stuff done.

Sorry!

I'm not sure what caused it for me, but I'm on XWayland 1.19 (fc28) and upon a reboot the keyboard was switched to us basic vs us dvorak (which is what I want). My underlying keymap is based on dvorak for the virtual console. tilex still used dvorak as I think that's a pure wayland app now. This has never happened before.

I cannot remember having this issue seen in a very long time, probably over a year.

(In reply to aappddeevv from comment #8)
> I'm not sure what caused it for me, but I'm on XWayland 1.19 (fc28) and upon
> a reboot the keyboard was switched to us basic vs us dvorak (which is what I
> want). My underlying keymap is based on dvorak for the virtual console.
> tilex still used dvorak as I think that's a pure wayland app now. This has
> never happened before.

In case you also updated xkeyboard-config to 2.24 (landed in updates-testing <40 hours ago), you might be running into this bug https://bugzilla.redhat.com/show_bug.cgi?id=1587998 instead.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/696.