Ctrlが押しっぱなしになる犯人はマウスだった

5月ごろから、たまに修飾キーが押しっぱなしになったような挙動が出ていました。クリックの挙動が変になる。c だけ文字が打てなくなる。キーボードをつなぎ直しても直らないのに、再起動すると直る。

環境は KDE Plasma の Wayland セッションです。なので最初に疑ったのも、それらしい層でした。KWin が修飾キーの状態を抱え込んでいるのか、KAccess の固定キー機能か、fcitx5 か。候補はどれももっともらしくて、fcitx5 -r や KAccess の再起動のような対処も一通り考えました。

転機は、また発生したときに再起動しなかったことです。ローカルでは文字が打てないので SSH で入りました。おかげで、壊れた状態を保存したまま調べられました。

決め手はカーネル側の evdev の押下状態です。

/dev/input/event18 Logitech G304 pressed: KEY_LEFTCTRL, KEY_C

KEY_LEFTCTRL と KEY_C を押しっぱなしにしていたのは、キーボードではなくマウスでした。使っている HHKB 側は何も押していません。c だけ打てなくなっていたのは、ずっと Ctrl+C が押されていたからでした。

マウスがキーを押すのは、変な話ではありません。udev から見ると G304 は ID_INPUT_MOUSE=1 と ID_INPUT_KEYBOARD=1 の両方を持っています。ゲーミングマウスはボタンにキー入力を割り当てられるので、HID としてはキーボードでもあるわけです。

復旧は、セッションの再起動ではなく、該当する USB インターフェイスだけの再バインドで済みました。

sudo sh -c 'echo -n 1-12:1.2 > /sys/bus/usb/drivers/usbhid/unbind; sleep 1; echo -n 1-12:1.2 > /sys/bus/usb/drivers/usbhid/bind'

1-12:1.2 はそのときのパスです。ポートや再起動で変わるので、使い回す前に /proc/bus/input/devices で確認し直す必要があります。

原因の側は、まだ断定できていません。solaar や input-remapper のようなソフト側のリマッパは動いていなかったので、残る候補はマウスのオンボードプロファイルか、レシーバ側の状態です。とりあえずオンボードプロファイルを無効にして様子を見ています。

この件で覚えておきたいのは一つだけです。再起動で直る入力異常は、直す前に evdev の状態を見る。上の層から疑い始めるのは自然だけど、決め手は下の層にありました。