SUMMARY If Czech is one of the keyboard layouts, even if it's not currently active, Alt+a does not work in any program. The key combination Alt+a simply does not register. Even xev does not see this particular key combination as pressed. STEPS TO REPRODUCE 1. Add Czech to your keyboard layouts 2. Try to use Alt+a shortcut in any program OBSERVED RESULT Alt+a does not register, as if nothing was pressed EXPECTED RESULT Alt+a registers and works SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 22.04, also had this problem on Kubuntu 21.10 (available in About System) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I have found this discussion https://forums.opensuse.org/showthread.php/557817-Alt-a-does-not-work-in-KDE-desktop/ and this bug report https://bugzilla.opensuse.org/show_bug.cgi?id=1189180 regarding this issue
> Even xev does not see this particular key combination as pressed. This means the issue is deeper than any KDE code. I would encourage you to follow up with the XKB folks at https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/.
Thanks for your help. I opened an issue with xkeyboard-config here https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/320 . The problem was the default shortcut Alt+~ and that there is a ~ character on the A key on the third level of the Czech keyboard (AltGr+a outputs ~). It seems like when KDE handles shortcuts, it checks on all key levels of all added layouts looking for a match. This seemed very weird to me at first, but thinking about it a bit more I could see why KDE would want to handle shortcuts like that. So I'm not sure if this is the intended behavior or not, but I assume it is. With this knowledge I can now manage to figure out why some of my key combinations don't work by going through the keyboard layout definition file and the default shortcuts if this happens to me with anything else, but I think a regular user would never be able to figure this out on their own, and I imagine with some more unusual layouts there could be way more problems like this. For example in the Opensuse bug report I linked, there's a comment from someone with a Polish/Colemak layout that has issues with a bunch of key combinations that don't work. He says: ``` I am experiencing the same issue, but also with Polish and Colemak layouts. Currently I am unable to use Emacs keybindings such as Alt+w, Alt+h, Control+Alt+a etc. Weirdly enough Alt+a works for me. ``` And here's the same problem with a different key combination for someone with an Arabic layout https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/issues/160 . I'm not really sure how this could be properly solved, but I figured it'd be worth at least bringing this up.
Huh. Maybe it is out bug after all. What do you think, Andrey?
(In reply to sedmicha from comment #2) > The problem was the default shortcut Alt+~ and that there is a ~ character > on the A key on the third level of the Czech keyboard (AltGr+a outputs ~). > It seems like when KDE handles shortcuts, it checks on all key levels of all > added layouts looking for a match. > > This seemed very weird to me at first, but thinking about it a bit more I > could see why KDE would want to handle shortcuts like that. So I'm not sure > if this is the intended behavior or not, but I assume it is. intended behavior is not quite the same but similar. Added recently for Wayland session. For X11, it always worked that way if one of Latin layouts is added first in Settings. This functionality is actually implemented in Qt and we just call it from our compositor. The logic behind it is to make Global shortcuts work uniformly on any layout. So if physical key has some Global shortcut defined for Latin layout - it always takes place whatever actual layout you have active. Just for the case, please confirm it works on Wayland the same way. PS: it still doesn't clear to me why you don't get standard action defined for Alt+`, it should switch windows of one group. > For example in the Opensuse bug report I linked, there's a comment from > someone with a Polish/Colemak layout that has issues with a bunch of key > combinations that don't work. He says: > ``` > I am experiencing the same issue, but also with Polish and Colemak layouts. > Currently I am unable to use Emacs keybindings such as Alt+w, Alt+h, > Control+Alt+a etc. Weirdly enough Alt+a works for me. > ``` That might be a different problem, Alt+w, Alt+h etc. are probably not global shortcuts. But then it should be reproducible on any desktop environment.
As a workaround, you could try to place non-Czech Latin layout first. Should work at least on X11, maybe Wayland, too.
> As a workaround, you could try to place non-Czech Latin layout first. Should work at least on X11, maybe Wayland, too. I have a US English layout as the first option and Czech as the second. I just tried switching them around and the order doesn't seem to change anything. This was on X11. > it still doesn't clear to me why you don't get standard action defined for Alt+`, it should switch windows of one group. The strange thing I just realized is that I'm not even getting the Alt+~ action (switch windows of active application in reverse order) when this happens. KDE seems to just eat the key combination, but nothing happens. Yet unbinding the Alt+~ shortcut fixes the problem.
> Just for the case, please confirm it works on Wayland the same way. I just tried switching to a Wayland session and the problem seems to be completely gone. Alt+a works as intended even though Alt+~ is binded and I have the Czech layout added. It even works with the Czech layout active. So I guess this is indeed a bug and it only happens on X11.
Great, at least it works for Wayland. For X11 we don't use the same mechanism for searching Glabal shortcut suitable (as we don't use libxkbcommon there), thus is the problem. Hypothetically, fixable but I'm not sure if someone will bother..