SUMMARY *** Key combinations are consumed on press, not on release which leads to inability to activate some combinations at all. Let's say that I have 2 languages/layouts installed and I want my hotkey be CTRL+SHIFT to switch them. I will be unable to do any combination that has CTRL+SHIFT in it, like CTRL+SHIFT+S (Save as... in Kate) or CTRL+SHIFT+CURSOR_ARROW to select words one by one in a text, for example. Basically, it's a copy of this ancient xorg bug which will never be fixed upstream: https://gitlab.freedesktop.org/xorg/xserver/-/issues/258 *** STEPS TO REPRODUCE 1. Have 2 languages/layouts installed 2. Make them switch using hotkey CTRL+SHIFT 3. Open Kate and type "The quick brown dog" 4. CTRL+SHIFT+<- (LEFT ARROW) to select the last word 5. Type "fox" OBSERVED RESULT The layout had been switched on the 4 step (before you pressed an arrow, because the hotkey was consumed on press) and there was no word selection, instead of "fox" you typed some other symbols in another language/layout, resulting in a sentence "The quick brown ащчdog" (Cyrillic symbols for example) EXPECTED RESULT Layout switching didn't occur, you selected the word "dog" and it was replaced with newly typed "fox", resulting in a sentence "The quick brown fox" SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.15.32-1-MANJARO (64-bit) (available in About System) KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I was very disappointed in finding out that this behaviour is present in wayland, because I was convinced that this would be fixed there from the start (there are a couple of posts about it dating 10 or so years ago), since it's basic and core functionality that was present on windows forever (and in many linux distros for a long time when maintainers just silently patched xorg by default). I'm not sure if it's a KWin issue or just Wayland, but there's was a similar Weston bug reported in the git some time ago, so I assumed it had to do with a compositor.
IIRC Kwin's Modifier only shortcuts are trigger on release, could you check that? I don't know if we have them documented, here are the links: https://blog.martin-graesslin.com/blog/2016/08/modifier-only-shortcuts-available-in-plasma-5-8/ https://bucharjan.cz/blog/plasma-custom-modifier-only-shortcuts.html
(In reply to Andrey from comment #1) > IIRC Kwin's Modifier only shortcuts are trigger on release, could you check > that? > > I don't know if we have them documented, here are the links: > https://blog.martin-graesslin.com/blog/2016/08/modifier-only-shortcuts- > available-in-plasma-5-8/ > https://bucharjan.cz/blog/plasma-custom-modifier-only-shortcuts.html Hi Andrey! Thank you! I can say that in default Manjaro config I have the option to invoke the Application Launcher widget by releasing the Windows key. I'm not sure that Meta and Win keys are treated exactly the same technically, but anyways - it works on release. Hooray! Nothing happens if I just press it. Please advise on proper testing procedure if that is not enough. But if I: 1) Open the KDE System Settings GUI -> Input Devices -> Keyboard -> Advanced 2) Check the "Configure keyboard options" 3) Expand "Switching to another layout" 4) Pick any one of this bunch, for example: left alt, left ctrl, left win, left shift (and uncheck the rest) 5) And click Apply Then it would work on press anyway, I'm sorry to say.
(In reply to George from comment #2) > But if I: > 1) Open the KDE System Settings GUI -> Input Devices -> Keyboard -> Advanced > 2) Check the "Configure keyboard options" > 3) Expand "Switching to another layout" > 4) Pick any one of this bunch, for example: left alt, left ctrl, left win, > left shift (and uncheck the rest) > 5) And click Apply > > Then it would work on press anyway, I'm sorry to say. This is normal. Both Xorg and libxkbcommon implement triggering on press due historical reasons. With modifiers only shortcuts we have KWin-specific workaround. We could bind "change to the next layout" dbus function to some modifier key instead of XKB way you described, but that would work for single modifier only I guess.. (need to confirm) Theoretically we could implement combinations, too.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
For Modifier only shortcuts do not supporting multiple modifiers, please open another issue. Closing as XKB upstream.
Is there a chance to have this bug fixed on Wayland? For KWin Wayland I'm not aware of any workarounds. Old XKB patch (https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865.patch?h=xorg-server-bug865) doesn't help on Wayland.
(In reply to Yevhen from comment #6) > Is there a chance to have this bug fixed on Wayland? > For KWin Wayland I'm not aware of any workarounds. Old XKB patch > (https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865. > patch?h=xorg-server-bug865) doesn't help on Wayland. It will most likely never be fixed by Wayland because it inherited libxkbcommon, that employs this very bug/behaviour. As it was never fixed in Xorg, because the specification is just old and bad (but it worked for 40-something years and people are afraid to change something like that with no new spec in sight). There may be some kind of a solution by the KDE team, as was discussed here and elsewhere, but I doubt that, given little numbers of people who care or whatever. And there's also this argument that you can change your hotkeys to something like Win+Space (or any other ungodly combination) and pretend that this bug doesn`t exist. I know, it's sad, but even I did it in the end. Anyway, you can try and submit a bug as per Andrey's request. I'll gladly join the discussion.
(In reply to George from comment #7) > (In reply to Yevhen from comment #6) > > Is there a chance to have this bug fixed on Wayland? > > For KWin Wayland I'm not aware of any workarounds. Old XKB patch > > (https://aur.archlinux.org/cgit/aur.git/tree/freedesktop-bug-865. > > patch?h=xorg-server-bug865) doesn't help on Wayland. > > It will most likely never be fixed by Wayland because it inherited > libxkbcommon, that employs this very bug/behaviour. As it was never fixed in > Xorg, because the specification is just old and bad (but it worked for > 40-something years and people are afraid to change something like that with > no new spec in sight). > > There may be some kind of a solution by the KDE team, as was discussed here > and elsewhere, but I doubt that, given little numbers of people who care or > whatever. And there's also this argument that you can change your hotkeys to > something like Win+Space (or any other ungodly combination) and pretend that > this bug doesn`t exist. I know, it's sad, but even I did it in the end. > > Anyway, you can try and submit a bug as per Andrey's request. I'll gladly > join the discussion. Thanks for the answer and suggestion. The new issue is here → https://bugs.kde.org/show_bug.cgi?id=476353
As it turns out, there was an even older related bug report: https://bugs.kde.org/show_bug.cgi?id=420493