To reproduce: 1. Open the "Advanced" tab of `kcmshell5 kcm_keyboard`. 2. Enable "Configure keyboard options", and select (for example) "Caps Lock behavior > Make Caps Lock an additional Esc". Press "Apply". 3. Use a shortcut that involves the Esc key (e.g. Ctrl-Alt-Esc for xkill). The shortcut works when the actual Esc key is used, but not when the Caps Lock key is pressed, even though it should work like Esc. This is the instance where I first observed this. I've found another instance of the same problem where, after remapping Esc to F13, a global shortcut that is set to F13 is not triggered when I press the correct key. In `kcmshell5 keys`, the mapping is applied correctly. For example, if I click on one of the recording button and press the Esc key, it fills in "F13" as desired. Same for the Caps Lock key, which produces "Esc" in the input field. One noteworthy detail: This problem only happens when I use the keyboard options that kcm_keyboard presents, i.e. the symbols options from /usr/share/X11/xkb/rules/evdev et al. When I do not use keyboard options and instead employ an Xmodmap like below, everything works correctly. $ cat .Xmodmap clear Lock keycode 0x42 = Escape keycode 0x09 = F13
Does the problem persist after restarting kglobalacceld5?
After restarting kglobalaccel5 with `killall kglobalaccel5 && sleep 3 && kglobalaccel5 &`, the affected shortcuts start working.
This is a well known limitation in Qt. We don't get any events which tell us that the mapping changed. After a restart we have the correct mapping. This is unfortunately rather a corner case. Changing any aspect of the code is dangerous due to the X nature. Wayland will fix it.