https://bugs.kde.org/show_bug.cgi?id=522619
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from [email protected] --- The same root cause affects the main number row, with no numpad and no NumLock involved, so this bug is more general than the summary suggests. Reproducer on KWin 6.7.4 / Qt 6.10.2, Debian sid, Wayland, us,ru layouts: 1. Bind "Switch to Desktop 1" to Meta+1. 2. Bind "Window to Desktop 1" to Meta+Shift+1. 3. Press Meta+Shift+1. Observed: the active window is not moved; the session switches to desktop 1, i.e. the Meta+1 action fires. Expected: the window moves to desktop 1. The binding itself is fine -- kglobalaccel has it registered and grabbed: $ qdbus6 --literal org.kde.kglobalaccel /kglobalaccel \ org.kde.KGlobalAccel.getGlobalShortcutsByKey 301989937 [Argument: (ssssssaiai) "Window to Desktop 1", "Window to Desktop 1", "kwin", "KWin", ... [Argument: ai {301989937}] ...] (301989937 = 0x12000031 = Meta|Shift|Qt::Key_1.) So the shortcut is stored and held correctly; the key event simply never reaches it with Shift set. Root cause is in Xkb::modifiersRelevantForGlobalShortcuts() in src/xkb.cpp, which ends with: Qt::KeyboardModifiers consumedMods = m_consumedModifiers; if ((mods & Qt::ShiftModifier) && (consumedMods == Qt::ShiftModifier)) { // test whether current keysym is a letter // ... see BUG: 370341 if (QChar::isLetter(toQtKey(m_keysym, scanCode, Qt::ControlModifier))) { consumedMods = Qt::KeyboardModifiers(); } } return mods & ~consumedMods; Shift is dropped whenever xkb consumed it to select the level, and the exception added for bug 370341 restores it only for letters. So the behaviour splits purely on whether the shifted keysym is a letter: - key <AE01> { [ 1, exclam ] }; (TWO_LEVEL, Shift selects level 2) -> Shift consumed, not a letter -> stripped. Meta+Shift+1 arrives as Meta+1. Same for the rest of the digit row and for punctuation. - Shift+W -> letter -> Shift restored by the 370341 exception, works. - key <PRSC> { type= "PC_ALT_LEVEL2", [ Print, Sys_Req ] }; -> level 2 needs Alt, so Shift is never consumed -> Meta+Shift+Print works. The numpad case in this report is the same mechanism: with NumLock on, the NumLock modifier already selects the level, so Shift is consumed and dropped. Consequence: Meta+Shift+<digit> cannot be bound to anything on Wayland, and it is indistinguishable from Meta+<digit> -- there is no spelling that reaches kglobalaccel. This is the standard i3/awesome/dwm idiom for "send window to workspace N", which is why it keeps being reported against KWin's own "Window to Desktop N" actions (this bug was found the same way). The reasoning behind the 370341 exception -- that a user-chosen shortcut should survive a shift that xkb happened to consume -- applies unchanged to digits and punctuation, and KWin already computes the unshifted key via toQtKey(m_keysym, scanCode, Qt::ControlModifier) in that very condition. Possibly also worth retitling this bug, since it is not numpad-specific, and moving it from effects-window-management to the input component. Related: bug 434988 covers the settings UI side, recording Meta+! where the user pressed Meta+Shift+1. -- You are receiving this mail because: You are watching all bug changes.
