以下の二つの crate を使って簡単なものを書いた:
あまりちゃんとした事はやってなくて、とりあえず入力されたキーを別のキーに変換できるか試してみた程度。
https://github.com/buzztaiki/rust-evdev-uinput-example
- Pure Rust。
- わりと使いやすいように思う。
- SYN_DROPPED も透過で処理してくれるのは良い。
- evdev-rs に以下のコメントがあったけど、今回使った範囲では困る事もなかった。
but it will miss out on any more complex handling that libevdev provides
- あまり頻繁な更新はない。
- libevdev のラッパー。
- わりと薄い。
- ffi は evdev-sys crate。
- 少し低レイヤな感じで、使いやすくはない。libevdev に慣れてれば問題はなさそう。
- メンテは続いている。上流の libevdev も当然メンテは続いている。
- デバイスを grab して、他のプロセスがそのデバイスを触れないようにする
- プロセスが終わると ungrab されるから、後処理は必要ない。ぽい。
- uinput デバイスを作る
- 入力可能なキーは全て列挙しておく必要がある。
- 元のデバイスからの入力イベントを変換して uinput デバイスに流す。
実体は ioctl によるデバイスのコントロールと、/dev/input, /dev/uinput の読み書き。
- https://www.freedesktop.org/software/libevdev/doc/latest/
- https://gitlab.freedesktop.org/libevdev/libevdev
- https://www.freedesktop.org/software/libevdev/doc/latest/syn_dropped.html
- https://www.kernel.org/doc/html/v5.12/input/input_uapi.html
- https://www.kernel.org/doc/html/v5.12/input/uinput.html
- https://www.kernel.org/doc/Documentation/input/event-codes.txt
- http://www.tatapa.org/~takuo/input_subsystem/input_subsystem.html
- https://stackoverflow.com/questions/41995349/why-does-ioctlfd-eviocgrab-1-cause-key-spam-sometimes