什么是抓住我的 Ctrl+s 键？

Question

刚刚升级到 Linux Mint 18.1 KDE（Plasma 5.8.5，Qt 5.6.1）除了我以前从未遇到过的奇怪问题外，一切都很好。某些东西在 X-window 级别上抓取了我的“Ctrl+s”序列，因为它从未达到应用程序级别。因此，例如“Ctrl+s”和“Ctrl+x Ctrl+s”标准 emacs 键都不起作用。即使在更典型的 KDE 程序中，“Ctrl+s”序列也已失效。我想这也可能是 KDE 框架，但没有定义为 Ctrl+s 的全局热键（我已将全局 Ctrl+s 移至 Ctrl+Shift+s）

这是铃声；它只是死了的“Ctrl + s”序列。所有其他的，据我所知，Ctrl 键按预期工作。

从 running 中可以获得一些关于正在发生的事情的线索xev。键入 Ctrl+s 生成以下序列

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

这与例如按下 Ctrl+y 完全不同。Ctrl+s 序列生成“FocusOut”和“FocusIn”，这是核心问题。这表明某些进程正在获取序列，可能是 KDE 窗口管理器。但是，我终其一生都无法确定是哪个过程在抓住关键。

我的理论通过showkey -a在终端中运行得到证实。它清楚地证实了应用程序 elevel 永远不会收到 Ctrl+s。例如，所有其他 Ctrl+ 都给出了一个键码

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

但是，尝试键入 Ctrl+s 并没有任何反应。

此外，我已经两次（和三次）检查了 KDE 中没有映射到 Ctrl+s 的全局热键，Ctrl+s 实际上也没有做任何事情。好像是直接发送到/dev/null ...

我也试过

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

看看我是否能找到正在抓取 Ctrl+s 键的进程。但是，我无法从日志中识别出任何此类过程。

我开始没有想法了，希望有人知道下一步该往哪里看？

Answer 1

在分析Xorg.0.log中更多的细节表明，Ctrl+s被消耗的kglobalaccel5过程，是韦兰/ KDE全局热键经理。

但是，由于我知道没有Ctrl+s键定义为全局热键，唯一的解决方案是这是键映射冲突（或者更确切地说是键和弦冲突）。

事实证明（经过一些反复试验），Ctrl+§我的键盘上的结果键事件与Ctrl+s（我曾经映射Ctrl+§以打开“仪表板小部件”）相同

很可能是因为我使用了通用键盘映射，而不是特定于我的“rapoo”-快速打字键盘。我没有关于键 + 修饰符的交互如何导致这种碰撞的详细知识。普通键，即 's' 和 '§' 单独工作，但显然将它们与 'Ctrl' 修饰符一起使用会给出相同的和弦值。

解决方案是删除全局映射 Ctrl+§

有趣的问题！