Keyboard shortcuts stop working intermittently

edit: As can be seen from the answer, this actually had nothing to do with standby or hibernation, but rather that it correlated with me often closing the app window (which triggered the bug) before going into standby most of the time.

I have seen multiple people report this in various places on the net, without any solution, but thought I would add mine in any case:

Very often, after returning to the computer after some time (when it has gone into standby), I notice that some shortcuts have stopped working. This does not only happen in the terminal, but also in Chrome (Ctrl-L, Ctrl-R, F5 all stops working). It also does not affect all ctrl-shortcuts: Ctrl-C is still working for instance (thank God!).

Is there any way of debugging this? Trying out xev earlier hasn't gotten me anywhere, but perhaps there is some way of finding out what is preventing my keypresses from reaching the programs?

edit: I can see something weird happening with Ctrl-R

Something is grabbing the keyboard shortcut!

Output captured from xev

KeyPress event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24547557, (-130,529), root:(0,633),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

FocusOut event, serial 37, synthetic NO, window 0x5200001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 37, synthetic NO, window 0x5200001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 37, synthetic NO, window 0x0,
    keys:  4294967278 0   0   0   0   0   0   0   0   0   0   0   0   2   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24548550, (-130,529), root:(0,633),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Compare this to Ctrl-C

we can easily see four logical events happening here

KeyPress event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24724066, (572,852), root:(702,956),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24724818, (572,852), root:(702,956),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XmbLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24724966, (572,852), root:(702,956),
    state 0x14, keycode 54 (keysym 0x63, c), same_screen YES,
    XLookupString gives 1 bytes: (03) ""
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 24725339, (572,852), root:(702,956),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Solution 1:

I managed to find the unlikeliest culprit: the Caprine Messenger app.! This could also happen with many other applications made with the Electron framework (Spotify, Atom, VS Code) until the bug in the shortcut library is fixed.

I now know how to consistently reproduce the bug after reading the bug report on the electron issue tracker: just close the app so that it just resides in the system tray. But before I got there I managed to find conclusive evidence that it was Caprine that was capturing the shortcut and that killing it solved the issue. This is how I found out (can be used for similar situations):

A somewhat opaque answer to a duplicate question of this explained that it was possible to detect which app was grabbing the keys by issuing some magic keystrokes. At first I did not understand quite how to set it all up, thinking I had to go through all sorts of hoops (messing with Xorg config, disabling vty switching, ++) to setup a special keymapping config, until it dawned on me that the answer actually also described how to trigger these key combinations programmatically!

So all I needed to do was opening two terminal windows. In the first terminal window I started logging events in the Xorg system:

tail -f /var/log/Xorg.0.log > out.txt

In the other window I triggered events that emitted the key combinations to the Xorg system:

KEY="ctrl+r"                  # the combination that was "grabbed"
xdotool keydown ${KEY};       # start pressing the key combo
xdotool key XF86LogGrabInfo;  # the keysym that when emitted asks X to print info on the grabber of the current keys
xdotool keyup ${KEY}          # stop pressing the key combo

Doing this programmatically like this was a lot easier than doing it manually like a finger octopus :-) In the event log captured in the other window (13'000 lines!) the interesting bits were apparent in the first few lines:

[ 24264.517]     detail 71 (mask 0), modifiersDetail 128 (mask 0)
[ 24264.517]     device 'Virtual core keyboard' (3), modifierDevice 'Virtual core keyboard' (3)
[ 24264.517]     core event mask 0x3
[ 24264.517]     owner-events false, kb 1 ptr 1, confine 0x0, cursor 0x0
[ 24264.517]   Printing all registered grabs of client pid 5643 /opt/Caprine/caprine --type=gpu-process --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=1,7,23,59,71 --gpu-vendor-id=0x8086 --gpu-device-id=0x5916 --gpu-driver-vendor --gpu-driver-version --gpu-driver-date --service-request-channel-token=B68A5099B5760C39675F51019B3D4F7A --v8-natives-passed-by-fd --v8-snapshot-passed-by-f 
[ 24264.517]   Printing all registered grabs of client pid 5643 /opt/Caprine/caprine --type=gpu-process --no-sandbox --supports-dual-gpus=false --gpu-driver-bug-workarounds=1,7,23,59,71 --gpu-vendor-id=0x8086 --gpu-device-id=0x5916 --gpu-driver-vendor --gpu-driver-version --gpu-driver-date --service-request-channel-token=B68A5099B5760C39675F51019B3D4F7A --v8-natives-passed-by-fd --v8-snapshot-passed-by-f 
[ 24264.517]   Printing all registered grabs of client pid 5684 /usr/lib/slack/slack --disable-gp 
[ 24264.517]   Printing all registered grabs of client pid 5684 /usr/lib/slack/slack --disable-gp 
[ 24264.517]   Printing all registered grabs of client pid 18336 xdotool key XF86LogGrabInfo
[ 24264.517] End list of registered passive grabs
[ 24308.177] (II) Printing all currently active device grabs:
[ 24308.177] Active grab 0x44800160 (core) on device 'Virtual core keyboard' (3):
[ 24308.177]       client pid 5614 /opt/Caprine/caprine 
[ 24308.177]       at 24308139 (from passive grab) (device thawed, state 1)
[ 24308.177]         core event mask 0x3
[ 24308.177]       passive grab type 2, detail 0x1b, activating key 27
[ 24308.177]       owner-events false, kb 1 ptr 1, confine 0, cursor 0x0
[ 24308.177] (II) End list of active device grabs

After killing Caprine, I could finally start using Ctrl-R in the terminal again to do reverse history searches, as well as refresh Chrome! xev also outputs something quite different from what I detailed in the question, now being very similar to the output from Ctrl-L:

KeyPress event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25356738, (917,877), root:(1047,981),
    state 0x10, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25357181, (917,877), root:(1047,981),
    state 0x14, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (12) ""
    XmbLookupString gives 1 bytes: (12) ""
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25357315, (917,877), root:(1047,981),
    state 0x14, keycode 27 (keysym 0x72, r), same_screen YES,
    XLookupString gives 1 bytes: (12) ""
    XFilterEvent returns: False

KeyRelease event, serial 39, synthetic NO, window 0x5200001,
    root 0xee, subw 0x0, time 25357710, (917,877), root:(1047,981),
    state 0x14, keycode 105 (keysym 0xffe4, Control_R), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

edit: Turns out the bug is known

The bug issue also shows how to consistently reproduce this (minimize). It was caused by a bug in the electron-localshortcut library.

Made a small util to easily send these shortcuts programmatically.

Keyboard shortcuts stop working intermittently

Solution 1:

Related

Recent Posts