SUMMARY KWin seems to steal focus when the key combination Alt+= is pressed, but I can't figure out what it does exactly. This is a problem for me because I typically use this hotkey in Emacs to do a specific task. However, since KWin steals the focus every time Alt+= is pressed, I can't use it in Emacs. STEPS TO REPRODUCE Open xev and press Alt+=. The following is a commented output from my machine: # Alt pressed: KeyPress event, serial 40, synthetic NO, window 0x5800001, root 0x1c9, subw 0x0, time 3737607, (61,104), root:(1461,133), state 0x0, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False # = pressed: FocusOut event, serial 40, synthetic NO, window 0x5800001, mode NotifyGrab, detail NotifyAncestor FocusOut event, serial 40, synthetic NO, window 0x5800001, mode NotifyUngrab, detail NotifyPointer FocusIn event, serial 40, synthetic NO, window 0x5800001, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 40, synthetic NO, window 0x0, keys: 4294967241 0 32 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 # = released: KeyRelease event, serial 40, synthetic NO, window 0x5800001, root 0x1c9, subw 0x0, time 3738919, (61,104), root:(1461,133), state 0x8, keycode 21 (keysym 0x3d, equal), same_screen YES, XLookupString gives 1 bytes: (3d) "=" XFilterEvent returns: False # Alt released: KeyRelease event, serial 40, synthetic NO, window 0x5800001, root 0x1c9, subw 0x0, time 3739829, (61,104), root:(1461,133), state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False You can see things like FocusIn and FocusOut, which means that a KDE process is invoked by the key combination. I believe this is related to KWin because when I close KWin, killall kwin_x11 the shortcut becomes available in Emacs and other applications (it's not intercepted by KWin). If I then start KWin, kwin_x11 & the shortcut becomes again bound to a KWin and is not available by other applications. I went through all the global and standard shortcuts but nothing seems to be bound to Alt+=. The only way I can fix this is by assigning Alt+= to some action and then removing it which frees up the key combination. However, after a restart Alt+= is again bound to some unknown action. EXPECTED RESULT When this shortcut is disabled, it should stay disabled even after KWin restarts. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.2 ADDITIONAL INFORMATION This issue emerged about week ago. First reported here: https://forum.kde.org/viewtopic.php?f=66&t=155962. A similar issue reported here: https://forum.kde.org/viewtopic.php?f=63&t=155960.
KWin does by default not use this shortcut. Most likely you have an app taking this shortcut and trying to activate. KWin is not the reason, but just the mediator. You can try xev -root to see more events and figure out which window geta activated. I don't see a bug in KWin.
Thank you, this helped! If I run xev -root, then part of the output reads PropertyNotify event, serial 18, synthetic NO, window 0x1c9, atom 0x152 (CLIP_TEMPORARY), time 8285578, state PropertyNewValue which suggests it has something to do with copying text. Indeed, if I select some text in a text editor, press Alt+=, and then press the middle button, that text is pasted. I don't have an immediate solution here but I can probably figure it out.
That could be an accessibility feature which emulates mouse buttons.
Not sure if it means anything but if I switch to Plasma (Wayland), the problem disappears.
If you have text selected, the middle mouse button pastes that text. It doesn't mean pressing alt+= is assigned to copying text. I'm getting the same issue, but with my "9" key (I had to use the number pad to type that.) For me, with xev -root, pressing "9" gives: FocusIn event, serial 21, synthetic NO, window 0x111, mode NotifyGrab, detail NotifyInferior KeymapNotify event, serial 21, synthetic NO, window 0x0, keys: 1 0 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 PropertyNotify event, serial 21, synthetic NO, window 0x111, atom 0x14d (CLIP_TEMPORARY), time 67595257, state PropertyNewValue FocusOut event, serial 21, synthetic NO, window 0x111, mode NotifyUngrab, detail NotifyInferior PropertyNotify event, serial 21, synthetic NO, window 0x111, atom 0x14d (CLIP_TEMPORARY), time 67595259, state PropertyDelete My "9" key is not assigned to "copy" but to something else. If I go to Settings and Global Shortcuts configuration, go to an unused shortcut and press the reassign button, I can press "9" to assign it to that shortcut. If I then delete the assignment again without applying, I regain normal use of my "9" key (until the next reboot). I think there is definitely a bug here.
As the others, I also observe this buggy behavior. In my case, the issue happens with the shortcut "alt+;" and "alt+]". Beyond this being a bug in KWin or not, there seems to be a need of a way to tell what is bound to a shortcut.
I'm seeing the same thing, with the key "5" being mapped to some CLIP_TEMPORARY thingy. It's quite annoying. Plasma version .16.4.
Note: Killing kglobalaccel5 helps.
Thanks, although for me killing kglobalaccel5 kills too much. I'd still like to use some other shortcuts.
My particular problem was apparently reported here: https://bugs.kde.org/show_bug.cgi?id=390742 After assigning the Yakuake key to F12, the number 5 key works again.
Today I had this problem with Ctrl+Alt-T. I barely recall disabling this key combination, along with several others, in SystemSettings5, because they are used by Emacs. Suddenly Ctrl+Alt+T was undetected in Emacs. After Killing kglobalaccel5 Emacs can see that key combination again. After restarting kglobalaccel5 the key combination kept working on Emacs. So there is something fishy here. Operating System: Debian GNU/Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.17.0-1-amd64 (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-6700K CPU @ 4.00GHz Memory: 62,7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 530
I can confirm that killing kglobalaccel5 allowed me to use my "9" key as usual. But when I started kglobalaccel5 back up, the "9" key stopped working again. Interestingly, not only is pressing "9" problematic, but also pressing "alt gr"+"9". As a Swedish keyboard, it's supposed to give me the opposite of "[". But it DOES work to press "shift"+"9" to get a ")". Not sure why shift works and not alt-gr... I'm currently using KDE version 5.24.5-1 on Fedora 36. Kernel 5.17.12-300
Yesterday I noticed this problem with the key combinations Alt+2 and Alt+7. A temporary way to fix the issue was to assign those combinations to some actions in Settings->Shortcuts and then to remove them. After restarting the system the issue was back though. I removed all the keyboard layouts from the KDE settings and am using the one specified in 00-keyboard.conf. This seems to have fixed the issue permanently, although it is not ideal. Operating System: Arch Linux KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.108.0 Qt Version: 5.15.10 Kernel Version: 6.4.10-arch1-1 (64-bit) Graphics Platform: X11