web-dev-qa-db-ja.com

Ctrl + sキーをつかむのは何ですか？

Linux Mint 18.1 KDE（Plasma 5.8.5、Qt 5.6.1）にアップグレードしたばかりで、これまで遭遇したことのない奇妙な問題を除けば、すべてがうまく機能しています。アプリケーションレベルに到達しないため、Xウィンドウレベルで表示される「Ctrl + s」シーケンスを何かが取得しています。したがって、たとえば、「Ctrl + s」も「Ctrl + xCtrl + s」の標準emacsキーも機能しません。より一般的なKDEプログラムでも、「Ctrl + s」シーケンスは機能しません。これもKDEフレームワークである可能性があると思いますが、Ctrl + sとして機能しないグローバルホットキーはありません（グローバルCtrl + sをCtrl + Shift + sに移動しました）

そして、これが呼び出し音です。死んでいるのは「Ctrl + s」シーケンスだけです。他のすべての、私が知っているように、Ctrlキーは期待どおりに機能します。

何が起こっているかについてのいくつかの手がかりは、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を入力しようとしても、何も起こりません。

さらに、Ctrl + sにマップされたKDEにグローバルホットキーがないことをダブル（およびトリプル）チェックしました。また、Ctrl + sは実際には何もしません。/dev/nullに直接送信されているようです...

私も試しました

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

ctrl + sキーを取得しているプロセスを見つけることができるかどうかを確認します。ただし、ログからはそのようなプロセスを特定できません。

私はアイデアが不足し始めており、誰かが次にどこを見るべきかについてアイデアを持っていることを望んでいましたか？

keyboard-shortcutskdekeyboard
4
Johan

Xorg.0.logをより詳細に分析すると、Ctrl+sがWayland/KDEグローバルホットキーマネージャーであるkglobalaccel5プロセスによって消費されていることがわかりました。

ただし、グローバルホットキーとして定義されたCtrl+sキーがないことを知っていたので、唯一の解決策は、これがキーマップの衝突（またはキーコードの衝突）であったことでした。

キーボードのCtrl+§の結果のキーイベントはCtrl+sの場合と同じであることが（試行錯誤のテストの結果）判明しました（以前はCtrl+§をマップして「ダッシュボード」を開きましたウィジェット」）

おそらく、汎用キーボードマッピングを使用していて、「rapoo」（クイックタイピングキーボード）に固有ではないためです。キーと修飾子の相互作用がどのようにこの衝突を引き起こす可能性があるかについての詳細な知識がありません。通常のキー、つまり「s」と「§」は個別に機能しますが、「Ctrl」修飾子と一緒に使用すると、同じコード値が得られるようです。

解決策は、Ctrl+§のグローバルマッピングを削除することでした。

面白い問題！

5
Johan