Bug 365255 - On x11 with multiple layouts, kglobalacceld grabs keys it shouldn't
Summary: On x11 with multiple layouts, kglobalacceld grabs keys it shouldn't
Status: CONFIRMED
Alias: None
Product: frameworks-kglobalaccel
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 6.5.0
Platform: Mint (Ubuntu based) Linux
: NOR normal
Target Milestone: ---
Assignee: kdelibs bugs
URL:
Keywords: X11-only
Depends on:
Blocks:
 
Reported: 2016-07-08 21:11 UTC by Eric Forgeot
Modified: 2025-02-27 19:54 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
kglobalshortcutsrc (32.06 KB, text/plain)
2016-07-12 19:46 UTC, Eric Forgeot
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Forgeot 2016-07-08 21:11:37 UTC
(using KDE 4.14.2)

I couldn't use an alt+7 shortcut in an application. I discovered KDE was intercepting it and modified the output. I thought it was a shortcut already used in the KDE system, but couldn't find anything relevant in the shortcut settings.

Reproducible: Always

Steps to Reproduce:
1. launch xev
2. test alt+6
3. test alt+7

Actual Results:  
xev returns this for alt+6:

KeyPress event, serial 42, synthetic NO, window 0x5a00001,
    root 0x28f, subw 0x0, time 323174779, (-206,579), root:(2110,608),
    state 0x18, keycode 15 (keysym 0x36, 6), same_screen YES,
    XLookupString gives 1 bytes: (36) "6"
    XmbLookupString gives 1 bytes: (36) "6"
    XFilterEvent returns: False

and for alt+7:


KeymapNotify event, serial 42, synthetic NO, window 0x0,
    keys:  2   0   1   0   0   0   0   0   1   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 42, synthetic NO, window 0x5a00001,
    root 0x28f, subw 0x0, time 323178411, (-206,579), root:(2110,608),
    state 0x18, keycode 16 (keysym 0x37, 7), same_screen YES,
    XLookupString gives 1 bytes: (37) "7"
    XFilterEvent returns: False


Expected Results:  
this part shouldn't be there:

KeymapNotify event, serial 42, synthetic NO, window 0x0,
    keys:  2   0   1   0   0   0   0   0   1   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

I've encountered this on two different computers running linux mint 17.3 and KDE.
It doesn't happen with the xfce desktop for example.
Comment 1 Eric Forgeot 2016-07-08 21:14:40 UTC
just a precision: I'm generally using an azerty keyboard. In the application I need alt+7, so I remapped my keyboard with "setxkbmap us" to be able to use the correct keys (it does the same if I use "setxkbmap de" for example). When in qwerty mode, alt+shift+7 is working correctly btw.
Comment 2 Thomas Lübking 2016-07-09 06:24:57 UTC
Try to kill and restart kglobalacceld after altering the layout, the event is probably still being sucked by Qt. (KWin doesn't do shortcuts)
Comment 3 Martin Flöser 2016-07-11 06:57:41 UTC
I don't understand where the KeymapNotify event comes from and doubt that KGlobalacceld has anything to do with it.
Comment 4 Eric Forgeot 2016-07-12 17:33:32 UTC
I can confirm that killing kglobalaccel solves the problem. But if I start it again, the problem comes again, as if there was a shortcut assigned to this key combination. I can live without the shortcuts system so killing kglobalaccel is a good solution for my case.

I couldn't find any shortcut related to alt+7, and since there are several programs in the "configuration of keybindings" it's quite tedious to check them all. Which I did, but maybe not correctly. 

Yet, I tried to assign alt+7 to a random command, and the system didn't complain it was already assigned. Then I deleted the shortcut. And the problem is still present, so I suppose there is a bug somewhere. Why only alt+7 and not the other keys?
Comment 5 Martin Flöser 2016-07-12 18:02:37 UTC
could you please attach your ~/.config/kglobalshortcutsrc? It should contain the offending key.
Comment 6 Eric Forgeot 2016-07-12 19:46:57 UTC
Created attachment 100041 [details]
kglobalshortcutsrc

here it is. I've renamed it so it won't be used, but it's the same (but maybe it need to log out and in again).
Comment 7 Eric Forgeot 2016-07-12 20:03:07 UTC
I've also an installation of KDE on a different system, PC-BSD, under a virtual machine. I've logged out of KDE on my linux system, and logged in xfce instead (I don't have the alt+7 bug there). I've launched the PC-BSD machine, switched to US keyboard, and with xev I got the same extra data sent by the alt+7 combination:

KeymapNotify event, serial 42, synthetic NO, window 0x0, keys: 2 0 1 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 

(and only with this alt+7 combination, alt+1 to 6 are correct, alt+8, 9 and 0 too).
Comment 8 Martin Flöser 2016-07-13 06:17:23 UTC
I don't think that this is related to global shortcuts. Might it be that your keymap has a layout switch on alt+7?
Comment 9 Eric Forgeot 2016-07-13 21:34:46 UTC
I don't know but the keymap is working correctly with other desktop manager (such as xfce). Don't you get those extra "KeymapNotify event..." with alt+7 on your computer as well?
Comment 10 Jurica Vukadin 2018-12-06 12:42:39 UTC
I've been poking at this in my spare time. It seems Alt+7 (and Alt+1 as well, I'm using Croatian layout), gets intercepted by KGlobalAccelImpl::nativeEventFilter(), while the others do not. I've added some debug prints to KGlobalAccelImpl::nativeEventFilter() and get this when I hit Alt+7:
responseType:  2
Got XKeyPress event
keyQt= "8000037" (this is Qt::AltModifier | Qt::Key_7)

For others I only get "responseType: 85" when I hit the Alt key.

Any clues how I can chase this down further?
Comment 11 Jurica Vukadin 2019-01-02 18:23:11 UTC
It seems the 'grave' keysym (mapped to the 3rd level of the '7' key on Croatian layout) has something to do with this. Similarly, the 'asciitilde' keysym prevents Alt+1 from working. If I remove or replace the keysyms, or move them to the 1st or 2nd level, the shortcuts start working. I.e., for key 7 (AE07):

symbols[Group1]= [ 7,  slash, grave, dead_grave ] # default, doesn't work
symbols[Group1]= [ 7,  slash, dead_grave, grave ] # doesn't work
symbols[Group1]= [ 7,  grave, slash, dead_grave ] # works
symbols[Group1]= [ 7,  slash, 7, dead_grave ]     # works
symbols[Group1]= [ 7,  slash ]                    # works

Can also be reproduced with the German layout:

setxkbmap de
# dump the layout
xkbcomp $DISPLAY de.xkb

# edit the entry for the 7 key in de.xkb, e.g.:
# -        symbols[Group1]= [               7,           slash,       braceleft,    seveneighths ]
# +        symbols[Group1]= [               7,           slash,       grave,    seveneighths ]

# set the modified layout
xkbcomp de.xkb $DISPLAY

Alt+7 is busted now.

Also, it seems bugs #310881 and #398069 are the same as this one.
Comment 12 Jurica Vukadin 2024-08-03 07:40:17 UTC
Doesn't happen on Wayland.
Comment 13 fanzhuyifan 2024-08-04 17:40:29 UTC
Is this still an issue as of plasma 6.1?
Comment 14 Jurica Vukadin 2024-08-04 17:44:40 UTC
Yes, still happens on X11 with plasma 6.1.3, frameworks 6.4, Qt 6.7.2 (arch packages)
Comment 15 fanzhuyifan 2024-08-04 18:36:11 UTC
Can reproduce. The issue is that xgrabkey operates by keycode, not by keysym. So kglobalacceld also grabs Alt+7, when it is trying to grab Alt+`.
Comment 16 fanzhuyifan 2024-08-04 19:23:41 UTC
xfce doesn't seem to have this issue because they do filtering by group when grabbing keys (e.g., the code around https://github.com/xfce-mirror/libxfce4ui/blob/f80584778709c70de02c4415f210a02b78fe6be5/libxfce4kbd-private/xfce-shortcuts-grabber.c#L344)

On the other hand, xfce doesn't seem to correctly handle the Alt+Shift+7 shortcut under the croatian layout. If I assign that to a shortcut, it is never triggered when I press that again.

To fix the issue in kglobalacceld, I guess the grabber needs to be more careful about what key+modifiers it grabs. E.g., don't grab Alt+7 without other modifiers if we want the shortcut Alt+`, and ` is mapped to the 7 key under the croatian layout.

However, given that this is a x11-only issue, and most devs are on wayland, I doubt if this issue would be prioritized by the devs.
Comment 17 TraceyC 2025-02-24 17:58:54 UTC
Adding the x11-only keyword
Comment 18 jww 2025-02-27 19:54:28 UTC
SOLUTION: Settings > Window Management > Taks Switcher: remove the current application shortcuts (Alt+` and Alt+~)

Other layouts use the RIGHT ALT (ISO_Level3_Shift) to modify keys. KDE has some sort a bug that understands the LEFT ALT as a modifier for the keys. You can check, the keys you are having trouble some how modify to either ` or ~.

See the whole explanation in: https://bugs.kde.org/show_bug.cgi?id=310881#c17