My X11 keyboard layout is set to the german neo layout. I can reproduce this regardles of whether I choose neo or normal german keyboard layout via tha KDE keyboard layout setting. In both layouts, it's the key right next to the left shift key. So with german layout I can't type Shift+A, with neo, I can't type Shift+U. It's still very likely that this is related to using neo layout (but I can't test it on a clean machine), because the keys Mod4+U (physical A key) / Mod4+O (physical G key) are alternative Home / End keys in neo. It seems like kglobalaccel (or the underlying Qt) are somehow overreacting and filtering out Shift+U too because Mod4+U would be the targeted Home key. Here's the output of xev for Shift+A and Shift+S via german keyboard layout. It seems like the KeyPress Event for Shift+A can't be decoded to "A". KeyPress event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4513962, (73,104), root:(73,518), state 0x2000, keycode 50 (keysym 0xffe1, Shift_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4514652, (73,104), root:(73,518), state 0x2001, keycode 30 (keysym 0x55, U), same_screen YES, XKeysymToKeycode returns keycode: 38 XLookupString gives 1 bytes: (55) "U" XmbLookupString gives 1 bytes: (55) "U" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4514723, (73,104), root:(73,518), state 0x2001, keycode 30 (keysym 0x55, U), same_screen YES, XKeysymToKeycode returns keycode: 38 XLookupString gives 1 bytes: (55) "U" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4515127, (73,104), root:(73,518), state 0x2001, keycode 50 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4544507, (77,91), root:(77,505), state 0x2000, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeymapNotify event, serial 28, synthetic NO, window 0x0, keys: 4294967191 0 0 0 64 0 0 64 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyRelease event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4545002, (77,91), root:(77,505), state 0x2001, keycode 38 (keysym 0x41, A), same_screen YES, XKeysymToKeycode returns keycode: 40 XLookupString gives 1 bytes: (41) "A" XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0xa00001, root 0x97, subw 0x0, time 4545352, (77,91), root:(77,505), state 0x2001, keycode 62 (keysym 0xffe5, Caps_Lock), same_screen YES, XKeysymToKeycode returns keycode: 50 XLookupString gives 0 bytes: XFilterEvent returns: False Reproducible: Always Steps to Reproduce: 0. Probably: Use neo as X11 keyboard layout setting 1. Custom Shortcuts > New > Global Shortcut > Command 2. Trigger: Shift+Home 3. Action: notify-send "hi" 4. Try to enter the large letter U in any textbox Actual Results: nothing happens Expected Results: a large letter "U" is entered. I'm using current KDE via ArchLinux (Qt 5.7.0, KF 5.24.0, Plasma 5.7.2)
This Bug also happens for other `Shift+(neo Mod4 keys)` shortcuts like: `Shift+Left` -> large "I" can't be entered: Mod4+I = Left A simple qt application with two QShortcuts: Shift+I and Shift+Left can detect both shortcuts correctly. But since in our case Shift+I is not a shortcut I don't know how useful this information is. Neo-Layout: http://neo-layout.org/ System: Kde neon user edition
I can confirm this bug. This bug also happens for all cobinations between Ctrl and Pos1/End/PgUp/PgDown/etc.—in which case Ctrl+A/O/Q/W/etc. do not work anymore. I'm using KDE via Debian Stretch (Qt 5.7.1, KDE Frameworks 5.28, Plasma 5.8 and Applications 16.08)
Confirmed here. I use Neo2 exclusively. Besides that, these global shortcuts do not even work themselves. Operating System: KDE neon 5.22 User edition KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.3 Kernel Version: 5.11.0-37-generic (64-bit) Graphics Platform: X11
Created attachment 142927 [details] Patch for KGlobalAccel 5.87.0 that fixes the issue. Here is what I have found after digging through the code for a while. The problem lies with KGlobalAccel registering keyboard grabs for every keycode that could possibly create the desired keysym, regardless of the state of the Mod5 (Neo Mod3) and Mod3 (Neo Mod4) modifiers. The function in question is KGlobalAccelImpl::grabKey in src/runtime/plugins/xcb/kglobalaccel_x11.cpp (KGlobalAccel). I have written a patch that should fix this issue, but I have only tested it with Neo, so it might break with other layouts. The patch is for KGlobalAccel version 5.87.0, but the offending code is 6 years old by this point so it should work pretty much everywhere. The fact that global shortcuts are not actually triggered when using the Neo layers 3 and above, is a separate bug in KWindowSystem, where the XKeyPressEvent is not translated to the correct keysym and only the first two columns of the keysym table (Neo layers 1 and 2) are checked. Anyone interested in fixing this can check out xcbKeyPressEventToQt() in src/platforms/xcb/kkeyserver.cpp (KWindowSystem). Furthermore, shortcuts containing dead keys or Unicode characters seemingly do not even get to the point of registering a keyboard grab, whereas others, like ÄÖÜ do register a grab, but are still not triggered correctly.