键盘快捷键间歇性地停止工作

Question

编辑：从答案中可以看出，这实际上与待机或休眠无关，而是与我在大部分时间进入待机状态之前经常关闭应用程序窗口（触发错误）有关。

我在网上的各个地方看到很多人报告这个，没有任何解决方案，但我想无论如何我都会添加我的：

很多时候，在一段时间后（进入待机状态时）返回计算机后，我注意到某些快捷方式已停止工作。这不仅发生在终端中，而且发生在 Chrome 中（Ctrl-L、Ctrl-R、F5 都停止工作）。它也不会影响所有 ctrl-shortcuts：例如，Ctrl-C 仍然有效（感谢上帝！）。

有没有办法调试这个？xev早点尝试并没有让我到任何地方，但也许有某种方法可以找出阻止我的按键到达程序的原因？

编辑：我可以看到 Ctrl-R 发生了一些奇怪的事情

有东西抢了键盘快捷键！

捕获的输出 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

将此与 Ctrl-C 进行比较

我们可以很容易地看到这里发生的四个逻辑事件

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

Answer 1

我设法找到了最不可能的罪魁祸首：Caprine Messenger 应用程序。！在修复快捷方式库中的错误之前，使用 Electron 框架（Spotify、Atom、VS Code）制作的许多其他应用程序也可能发生这种情况。

在阅读了关于电子问题跟踪器的错误报告后，我现在知道如何一致地重现错误：只需关闭应用程序，使其仅驻留在系统托盘中。但在我到达那里之前，我设法找到了确凿的证据，证明是 Caprine 捕获了捷径并杀死了它解决了问题。我是这样发现的（可用于类似情况）：

对此重复问题的一个有点不透明的答案解释说，可以通过发出一些魔术击键来检测哪个应用程序正在抓取密钥。起初我不太明白如何设置它，以为我必须通过各种箍（弄乱 Xorg 配置，禁用 vty 切换，++）来设置一个特殊的键映射配置，直到我意识到答案实际上还描述了如何以编程方式触发这些组合键！

所以我需要做的就是打开两个终端窗口。在第一个终端窗口中，我开始在 Xorg 系统中记录事件：

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

在另一个窗口中，我触发了将组合键发送到 Xorg 系统的事件：

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

像这样以编程方式执行此操作比像手指章鱼一样手动执行要容易得多:-) 在另一个窗口（13'000 行！）中捕获的事件日志中，有趣的位在前几行中很明显：

[ 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

杀死 Caprine 后，我终于可以再次开始在终端中使用 Ctrl-R 进行反向历史搜索，以及刷新 Chrome！xev还输出与我在问题中详述的内容完全不同的内容，现在与 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

编辑：原来错误是已知的

该错误问题还显示了如何始终如一地重现（最小化）。这是由电子本地快捷方式库中的错误引起的。

制作了一个小工具，可以轻松地以编程方式发送这些快捷方式。