SUMMARY *** While the title suggests, that a lot of random things need to happen at the same time, i don't think this situation is as uncommon as it first seems. I've had the following in my .bashrc: `setxkbmap -option ctrl:nocaps 2>/dev/null`. While I totally agree, that x-keyboard-options should be set via config file rather than invoking them by the bashrc, it is however a totally legit way to archieve the desired behaviour (remap capslock in this case). However, if you have only one keyboard layout configured (just `de` in my case, no modified layouts), any use of xkbmap seems to break the layout, and - at least for some apps - reverts it to the `us`-layout (even it is not in my list of configured layouts). Even more strange is, that this only seem to affect some applications. For me the effect was most noticeable in firefox and thunderbird. I think it is not that uncommon for people switching from xorg to wayland to have some kind of options like this in some scripts. Especially annoying here is, that this will never be reproducible on new installs with a fresh homedir. Even though this clearly qualifies as "user-error", the keyboard should never ever fall back to an unconfigured layout, and behaviour like this is not very obvious to track down, because if you stare at it, you won't be able to observe the error until you start a new shell. As already assumed, calling xmodmap without redirecting the output, says that it is running against Xwayland, which might explain different behaviours in different windows. However, while having an xorg-compatibility layer is awesome, having multiple keyboard layouts active at the same time depending on the window is certainly not. any "apply" action in the "settingsmenu/input/keyboard" subsection reverts this behaviour to the expected state. I'd assume, there are alot of universal apps (flatpak..) that will be affected by this, too. *** STEPS TO REPRODUCE 1. put some `xmodmap` command in your .bashrc and start a terminal under wayland. Alternatively execute manually. OBSERVED RESULT - some applications like firefox and thunderbird end up with a default, but unconfigured and unlisted (in terms of the plasma settingsmenu) keyboard-layout (us). EXPECTED RESULT - keyboard-settings should be applied uniformly between apps regardless of wayland, Xwayland, flatpak, fullscreen-games, etc.. SOFTWARE/OS VERSIONS - Linux/KDE Plasma: Linux/6.3.4-arch1-1 - KDE Plasma Version: 5.27.5 - KDE Frameworks Version: 5.106.0 - Qt Version: 5.15.9 All-AMD-System (Ryzen7xxx/Navi31), Single Monitor Setup. Initially i thought this might be related to https://bugs.kde.org/show_bug.cgi?id=433576, but it turns out unrelated, as my behaviour perists with more than one layout as well. However, they seem somewhat similar anyways.
setxkbmap and xmodmap are X11-only tools and will not work with Wayland. So e.g. `setxkbmap -query` will most probably not gives you any meaningful information. In a Wayland session, the only way to check reliably your keymap in X11 is to use `xkbcomp $DISPLAY -` .
(In reply to Wismill from comment #1) > setxkbmap and xmodmap are X11-only tools and will not work with Wayland. So > e.g. `setxkbmap -query` will most probably not gives you any meaningful > information. In a Wayland session, the only way to check reliably your > keymap in X11 is to use `xkbcomp $DISPLAY -` . Yes, I know this. My point was, that this can be a very common configuration for anyone migrating from X11 to Wayland, and in this case, very unpredictable things do happen.
Note that setxkbmap should display the following warning: “WARNING: Running setxkbmap against an Xwayland server”. It may require a recent version. There is no tool to replace setxkbmap for Wayland; or rather: there is no *generic* (as in “for all DE”) tool to replace it. See the discussion at https://github.com/xkbcommon/libxkbcommon/issues/470#issuecomment-1998697198. It would be very useful to have a Plasma-specific tool to configure the keyboard config as setxkbmap.