Bug 401227 - Global hotkey resets with each restart
Summary: Global hotkey resets with each restart
Status: REOPENED
Alias: None
Product: kwin
Classification: Unclassified
Component: input (show other bugs)
Version: 5.14.3
Platform: Archlinux Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-11-19 21:53 UTC by Raul Laasner
Modified: 2019-08-27 12:15 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raul Laasner 2018-11-19 21:53:35 UTC
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.
Comment 1 Martin Flöser 2018-11-20 05:30:21 UTC
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.
Comment 2 Raul Laasner 2018-11-20 16:15:14 UTC
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.
Comment 3 Martin Flöser 2018-11-20 16:45:31 UTC
That could be an accessibility feature which emulates mouse buttons.
Comment 4 Raul Laasner 2018-11-20 20:03:53 UTC
Not sure if it means anything but if I switch to Plasma (Wayland), the problem disappears.
Comment 5 David 2019-02-20 23:46:54 UTC
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.
Comment 6 Carlos 2019-06-07 11:51:40 UTC
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.
Comment 7 Niels 2019-08-26 15:05:47 UTC
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.
Comment 8 Niels 2019-08-26 15:27:23 UTC
Note: Killing kglobalaccel5 helps.
Comment 9 Raul Laasner 2019-08-26 15:48:47 UTC
Thanks, although for me killing kglobalaccel5 kills too much. I'd still like to use some other shortcuts.
Comment 10 Niels 2019-08-27 12:15:38 UTC
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.