This is a long-standing bug for X.org (see https://bugs.freedesktop.org/show_bug.cgi?id=865, 13 years already; although it has a proposed patch, which is not accepted to upstream yet), and there is even an old bug in KDE bugzilla (Bug 114326). In wayland, apparently, things are quite different as the compositor - KWin - now handles everything including shortcuts, which brings a hope to resolve this issue once and for all. The current behavior is following: 1) I have two keyboard layouts, russian and english, and I use ctrl+shift for layout switching. 2) I open Konsole and press Ctrl+Shift+N in order to open new window 3) Right after I pressed Ctrl+Shift, the layout immediately switches. After I press "N", Konsole thinks I've pressed just Ctrl+N and thus ignores the shortcut (this I've checked via the KWin Debug Console), writing the "n" letter in the terminal. Clearly, switching the layout is not something I intended to do and this behavior is wrong. The original idea proposed in bugs.fd.o 865 is to trigger the shortcut (e.g. ctrl+shift) on key release instead of key press. Actually, there is a lot of discussion there, which might be useful.
I'm sorry, but I fear there is nothing we can do about this. The layout handling is handled by xkbcommon. That is we pass all key events to xkbcommon and xkbcommon transforms it to a key symbol and handles changes to the keyboard layout transparently. Whatever comes out from xkbcommon is then fed into other parts of KWin such as global shortcuts or send to other applications. We don't have any control over this at this point. In fact KWin is completely out of the game here as the shortcut matching is done inside Konsole, so inside Qt. Which again just forwards keys into xkbcommon. I don't know whether this can be fixed at all - I don't know the internals of all involved components enough. But I fear this is just an unfixable situation.
(In reply to Martin Flöser from comment #1) > I'm sorry, but I fear there is nothing we can do about this. The layout > handling is handled by xkbcommon. That is we pass all key events to > xkbcommon and xkbcommon transforms it to a key symbol and handles changes to > the keyboard layout transparently. Whatever comes out from xkbcommon is then > fed into other parts of KWin such as global shortcuts or send to other > applications. We don't have any control over this at this point. > > In fact KWin is completely out of the game here as the shortcut matching is > done inside Konsole, so inside Qt. Which again just forwards keys into > xkbcommon. > > I don't know whether this can be fixed at all - I don't know the internals > of all involved components enough. But I fear this is just an unfixable > situation. If it helps, XFCE seems to somehow have fixed this issue in whatever library they use, while all other DEs (KDE, Mate, old Gnome, etc.) still encounter this problem.
*** Bug 387500 has been marked as a duplicate of this bug. ***
Also if the issue is with xkbcommon, does it mean it can be fixed in wayland?
*** Bug 478323 has been marked as a duplicate of this bug. ***
FYI. I have opened an issue in libxkbcommon. https://github.com/xkbcommon/libxkbcommon/issues/420 If someone could raise it priority or put attention to it...