☰

是什么夺走了我的 Ctrl+s 键？

tag-icon • tag-icon keyboard-shortcuts kde keyboard
是什么夺走了我的 Ctrl+s 键？

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

这是铃声；只有“Ctrl+s”序列已失效。据我所知，所有其他键都按预期工作。

从跑步中可以获得一些关于正在发生的事情的线索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 键。然而，从日志中我无法识别任何此类过程。

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

答案1

Xorg.0.log更详细地分析表明，该进程被 Wayland/KDE 全局热键管理器进程Ctrl+s消耗。kglobalaccel5

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

事实证明（经过一些试验和错误测试）我键盘上产生的按键事件与（我曾经映射以打开“仪表板小部件”）Ctrl+§相同Ctrl+sCtrl+§

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

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

有趣的问题！

相关内容