What is grabbing my Ctrl+s key?

Question

Having just upgraded to Linux Mint 18.1 KDE (Plasma 5.8.5, Qt 5.6.1) all is working excellent apart from strange problem I never come across before. Something is grabbing my "Ctrl+s" sequence on what seems at the X-window level since it never reaches the application level. So for example neither "Ctrl+s" nor "Ctrl+x Ctrl+s" standard emacs keys work. Even in more typical KDE program the "Ctrl+s" sequence is dead. I guess this could be KDE framework as well but there is no global hotkey defuned as Ctrl+s (I've moved the global Ctrl+s to Ctrl+Shift+s)

And here is the ringer; Its is only the "Ctrl+s" seqeunce that is dead. All other, to me known, Ctrl keys works as expected.

Some clue to what is going on is gotten from running xev. Typing Ctrl+s generates the following sequence

KeyPress event, serial 40, synthetic NO, window 0x3400001,
    root 0x4c4, subw 0x0, time 14783934, (-711,685), root:(1159,750),
    state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 40, synthetic NO, window 0x3400001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 40, synthetic NO, window 0x3400001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 40, synthetic NO, window 0x0,
    keys:  2   0   0   0   4294967200 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   

KeyRelease event, serial 40, synthetic NO, window 0x3400001,
    root 0x4c4, subw 0x0, time 14784998, (-711,685), root:(1159,750),
    state 0x4, keycode 39 (keysym 0x73, s), same_screen YES,
    XLookupString gives 1 bytes: (13) ""
    XFilterEvent returns: False

KeyRelease event, serial 40, synthetic NO, window 0x3400001,
    root 0x4c4, subw 0x0, time 14785566, (-711,685), root:(1159,750),
    state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

This is quite different from, say, pressing, say Ctrl+y. The Ctrl+s sequence generates both a "FocusOut" and "FocusIn" which is the core problem. This indicates that some process is grabbing the sequence, possible the KDE window manager. However, I cannot for my life identify what process is grabbing the key.

My theory is confirmed by running showkey -a in a terminal. It clearly confirms that the application elevel never receives the Ctrl+s. All other Ctrl+ gives a keycode, for example

^Y       25 0031 0x19
^R       18 0022 0x12
^T       20 0024 0x14
^T       20 0024 0x14

However, trying to type Ctrl+s and nothing happens.

Furthermore I have double (and triple) checked that there are no global hotkeys in KDE mapped to Ctrl+s nor does the Ctrl+s actually do anything. It seems to be sent directly to /dev/null ...

I've also tried

xdotool keydown Ctrl+s;xdotool key XF86LogGrabInfo; xdotool keyup Ctrl+s;

to see if I can find what process is grabbing the Ctrl+s key. From the logs I cannot however, identify any such process.

I'm starting to run out of ideas and was hoping someone have an idea on where to look next?

Answer 1

Analyzing the Xorg.0.log in more details showed that Ctrl+s was consumed by the kglobalaccel5 process which is the Wayland/KDE global hot key manager.

However, since I knew there were no Ctrl+s key defined as a global hotkey the only solution was that this was a keymap collision (or rather a key chord collision).

It turned out (after some trial and error testing) that the resulting key events for Ctrl+§ on my keyboard was the same as for Ctrl+s (I used to map Ctrl+§ to open the "Dashboard Widget" )

Most likely because I use a Generic keyboard mapping and not specific for my "rapoo"-quick typing keyboard. I don't have the detailed knowledge of how the interaction of keys + modifier can result in this collision. The normal keys, i.e. 's' and '§' individually works but apparently using them together with the 'Ctrl' modifier gives the same chord value.

The solution was to remove the global mapping for Ctrl+§

Interesting problem!