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?

  • Have a look at this: unix.stackexchange.com/questions/137842/… – Rui F Ribeiro Feb 26 '17 at 19:20
  • 1
    Very related question, but the given answer appears to be what you've already tried, so not a duplicate. – Michael Homer Feb 26 '17 at 20:00
  • Thanks for the reply. However Flow control is not the issue here since this problem also relates to applications not started from the terminal. The TTY flow control only applies to terminal. For good measures I have also setup the terminal to ignore flow control with stty -ixon -ixoff with no effect. – Johan Feb 26 '17 at 21:46
  • If Ctrl+S does nothing in a terminal then the problem is at a lower level than X. But there shouldn't be anything lower than X hiding some keys, especially not when X is running. Do you have the same problem if you log in to a different account? Do you have the same problem if you boot a different OS? – Gilles 'SO- stop being evil' Feb 26 '17 at 21:48
  • 3
    Can you post the answer as an actual answer down below? You can accept it afterwards by clicking the checkmark on the left – Michael Mrozek Feb 26 '17 at 22:58

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!

  • 1
    FWIW, I had a similar issue on openSUSE Tumbleweed, Plasma 5.18.3 with a pc101/fr/latin9 keyboard setup. Alt+P was the victim rather than Ctrl+S. Although I didn't push the analysis as far as you did (I merely observed that Alt+P worked in XFCE and not in Plasma, and only in Plasma did xev show the same FocusOut/FocusIn/KeymapNotify events as you did), disabling the KWin shortcut for "Walk Through Windows of Current Application" (Alt+`) did the trick for me. Thanks for steering me toward the answer! – Peniblec Apr 5 '20 at 20:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.