| Summary: | Do not invoke two-modifiers keyboard shortcuts (like Alt+Shift) when used as part of other key combinations | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | zkdebugsk |
| Component: | input | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | xaver.hugl, zkdebugsk |
| Priority: | NOR | ||
| Version First Reported In: | git-stable-Plasma/5.27 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
zkdebugsk
2024-05-10 19:33:17 UTC
KWin doesn't do layout switching shortcuts, that's done in libxkbcommon - and this is a very old bug in it . See https://github.com/xkbcommon/libxkbcommon/issues/420 for more details From what I understand, KWin is the one detecting the keyboard layout switch key combination: https://invent.kde.org/plasma/kwin/-/blob/529c3c29d300345219f3fcc173b3022c087bf32d/src/keyboard_layout.cpp#L52 The fact that the actual key translation is eventually done by libxkbcommon, and that libxkbcommon is involved with sending the two KEYDOWN events to KWin, do not necessarily mean that it should be the right place to resolve the problem. A resolution within libxkbcommon can only be done by trying to implement a heuristic that will prevent or delay sending the second KEYDOWN event, and maybe wait to see what is pressed next etc.. But: 1) It is a hack 2) It does not have the context of what shortcuts are being used and what overlap there is between them, if any (Only KWin has this information 3) Such a hack will have to be implemented also in Wayland 4) There are bugs for it in X11 for many years (see https://gitlab.freedesktop.org/xorg/xserver/-/issues/258) and will not be resolved I would really love to see KDE resolving this many years old problem, especially when Windows has the right behavior that is easy to learn from - responding to a modifiers-only key sequence only when any modifier key is released. + I would love to help with anything except coding (as my C++ is rusty, and I don't have the dev/debug environment) The shortcut you linked is Qt::META | Qt::ALT | Qt::Key_K by default, not ctrl+shift (In reply to Zamundaaa from comment #3) > The shortcut you linked is Qt::META | Qt::ALT | Qt::Key_K by default, not > ctrl+shift Sorry, my bad, I thought that some black magic is loading the config in addition to META+ALT+K Found the real black magic that loads the confik from ~/.config/kxkbrc and calls xkb_keymap_new_from_names BTW, I still think that KWin should take over the custom keyboard switching shortcuts handling and support what Windows can. If I prepare a PR doing that, suppose it has an elegant implementation, will such PR be accepted, or this is a too radical change? (In reply to zkdebugsk from comment #5) > BTW, I still think that KWin should take over the custom keyboard switching > shortcuts handling and support what Windows can. > > If I prepare a PR doing that, suppose it has an elegant implementation, will > such PR be accepted, or this is a too radical change? If it's possible to handle it ourselves and disable the thing in libxkbcommon, I think that would be a reasonable path forward |