https://bugs.kde.org/show_bug.cgi?id=478208
--- Comment #11 from Wismill <d...@wismill.eu> --- As written above, this is Plasma bug, not an XKB one: the XKB action (locking Caps) is resolved while it should not, when Caps key is bound to a shortcut. In order to mitigate this, you may: 1. Use one of the XKB options to switch layouts. There are located in “Key bindings” (top right button from keyboard config), then look for the group “Switching to another layout”. The “Caps Lock” option in this group allow you to switch to cycle the layouts. But they are many other options which may fit better to your needs. 2. For power users: Tweak the XKB keymap by creating your own option. Follow the guide at: https://xkbcommon.org/doc/current/user-configuration.html#autotoc_md16: cat $XDG_CONFIG_HOME/xkb/rules/evdev ! option = symbols custom:caps = +my-caps ! include %S/evdev $ cat $XDG_CONFIG_HOME/xkb/symbols/my-caps partial alphanumeric_keys xkb_symbols "deactivate caps" { key <CAPS> { [ F35 ] }; }; and adapt the “Discoverable layouts” section of the linked example with the files above. Now re-open the keyboard settings and activate your brand new option: you should be able to bind the CapsLock *key* as described in this issue, *without* locking the Caps. It does not mess with systems files and it will survive an update of those. Note that I will not assist you further with tweaking XKB, so if you do not feel comfortable please stick with temp solution 1) and wait for the KDE devs to fix the issue. -- You are receiving this mail because: You are watching all bug changes.
