「Interception-tools」の版間の差分
細 (余分な空白を削除) |
細 (→複数のジョブを処理する: 修正) |
||
(同じ利用者による、間の3版が非表示) | |||
33行目: | 33行目: | ||
== 設定 == |
== 設定 == |
||
+ | interception-tools には、いくつかのコマンドラインツールと1つの [[systemd]] サービスが含まれています。 |
||
− | The tools comprise commandline tools and a [[systemd]] service. |
||
+ | パッケージに含まれている {{ic|udevmon.service}} を[[起動]]する場合は、まず先に {{ic|/etc/interception/udevmon.yaml}} に設定を追加しておく必要があります。 |
||
− | A configuration in {{ic|/etc/interception/udevmon.yaml}} needs to be added before [[start]]ing the packaged {{ic|udevmon.service}}. |
||
− | {{Note| |
+ | {{Note|{{ic|/etc/interception/udevmon.d/}} 内の設定ファイルがまず先に読み込まれ、その後に {{ic|/etc/interception/udevmon.yaml}} にフォールバックします。}} |
=== 仕組み === |
=== 仕組み === |
||
− | Interception-tool |
+ | Interception-tool は ''libevdev'' を使用します (''libevdev'' は、このライブラリの wiki によると、本質的には {{ic|/dev/input/eventX}} デバイス用に強化された {{man|2|read}} です)。 |
+ | ''libevdev'' は、イベントを処理するプロセスとカーネルとの間で動作します。 |
||
− | It sits in between the kernel and the process handling an event. |
||
+ | 最もシンプルなシナリオでは、以下のような感じになります: |
||
− | In the simplest scenario would look like this: |
||
− | + | カーネル | libevdev | evtest |
|
+ | X.Org 入力モジュールの場合、スタックは以下のようになります: |
||
− | For X.Org input modules, the stack would look like this: |
||
− | + | カーネル | libevdev | xf86-input-evdev | X サーバ | X クライアント |
|
+ | Wayland では、スタックは以下のようになります: |
||
− | For Wayland, the stack would look like this: |
||
− | + | カーネル | libevdev | コンポジタ | Wayland クライアント |
|
+ | 言い換えると、{{ic|libevdev}} は低レベルであるため、X/Wayland クライアントに関する情報を持ちません。 |
||
− | In other words, {{ic|libevdev}} is so low level that it does not have knowledge of X/Wayland clients. |
||
=== 実用例 === |
=== 実用例 === |
||
− | Interception-tools |
+ | Interception-tools では4つのユーティリティが使用できます: |
− | * {{ic|intercept}}: |
+ | * {{ic|intercept}}: デバイスの入力イベントを標準出力にリダイレクトする。 |
+ | * {{ic|mux}}: 入力イベントの複数のストリームを結合する。 |
||
− | * {{ic|mux}}: combine streams of input events, |
||
+ | * {{ic|udevmon}}: 入力デバイスを監視し、(それに応じて) タスクを開始する。 |
||
− | * {{ic|udevmon}}: monitor input devices for launching tasks, |
||
+ | * {{ic|uinput}}: 入力イベントを標準入力から仮想デバイスへリダイレクトする。 |
||
− | * {{ic|uinput}}: redirect device input events from stdin to virtual device. |
||
==== 実行優先度を上げる ==== |
==== 実行優先度を上げる ==== |
||
+ | このツールはデバイス入力の最も低いレベルで動作するため、{{ic|udevmon}} の実行優先度を上げて持続的に動作するようにしてください: |
||
− | Since the tool is going to be sitting down at the lowest level of the device inputs, |
||
− | make sure it will behave consistently by increasing {{ic|udevmon}} priority: |
||
# nice -n -20 udevmon -c udevmon.yaml > udevmon.log 2> udevmon.err & |
# nice -n -20 udevmon -c udevmon.yaml > udevmon.log 2> udevmon.err & |
||
− | {{Tip| |
+ | {{Tip|{{ic|udevmon}} systemd サービスは {{ic|1=Nice=-20}} で実行されます。}} |
==== シンプルなリダイレクト ==== |
==== シンプルなリダイレクト ==== |
||
+ | イベントを標準出力に (他に何もせずに) リダイレクトする最も単純な方法は: |
||
− | The simplest way or redirecting the event to the stdin (without doing nothing) is: |
||
$ intercept -g ''DEVNODE'' | uinput -d ''DEVNODE'' |
$ intercept -g ''DEVNODE'' | uinput -d ''DEVNODE'' |
||
− | + | {{ic|''DEVNODE''}} は実際のデバイスへのパスです (例: {{ic|/dev/input/by-path/platform-i8042-serio-0-event-kbd}})。 |
|
==== コマンドを挟む ==== |
==== コマンドを挟む ==== |
||
+ | キーイベントと入力との間で何か処理を行うには、その処理を {{ic|intercept}} と {{ic|uinput}} との間にパイプで挟んでください。 |
||
− | To actually perform an operation in between the key event and the input, simply pipe it in between {{ic|intercept}} and {{ic|uinput}}. |
||
− | + | 例えば、{{Pkg|interception-caps2esc}} プラグインをインストールし、以下のコマンドを実行してみてください: |
|
$ intercept -g ''DEVNODE'' | caps2esc | uinput -d ''DEVNODE'' |
$ intercept -g ''DEVNODE'' | caps2esc | uinput -d ''DEVNODE'' |
||
+ | {{ic|-g}} フラグを省略すると、デバイスイベントは単に''観測''されるだけで、捕捉 (grab) されません (訳注: {{ic|-g}} フラグを付けることにより、そのデバイスに排他的にアクセスできるようになります。そうすることで、{{ic|uinput}} によって作成された新しい仮想デバイスが元のデバイスイベントを処理後のデバイスイベントに完全に置き換えることができます。{{ic|-g}} を付けないと、処理される前の元のデバイスイベントが残ってしまいます。)。 |
||
− | If we omitted the {{ic|-g}} flag, then device event would have been just ''observed'', not grabbed. |
||
==== YAML で設定する ==== |
==== YAML で設定する ==== |
||
+ | 先の方法で入力をインターセプトするのは、すぐに最適ではなくなるかもしれません。そのような場合、{{ic|udevmon}} が役に立ちます。 |
||
− | This way of intercepting the input can quickly become sub-optimal, this is where {{ic|udevmon}} comes in handy. |
||
+ | udevmon は、ジョブ (デフォルトでは sh コマンド) のリストを含む YAML 設定ファイルを読み込み、それらを (適切な時に) 実行します。 |
||
− | udevmon accepts a YAML configuration with a list of jobs (sh commands by default) to be executed. |
||
+ | デバイスが記述とマッチする場合にジョブを実行する例: |
||
− | In case the device matches a given description: |
||
{{hc|$ udevmon -c caps2esc.conf.yml| |
{{hc|$ udevmon -c caps2esc.conf.yml| |
||
− | - JOB: intercept -g''DEVNODE'' {{!}} caps2esc {{!}} uinput -d ''DEVNODE'' |
+ | - JOB: intercept -g ''DEVNODE'' {{!}} caps2esc {{!}} uinput -d ''DEVNODE'' |
DEVICE: |
DEVICE: |
||
LINK: /dev/input/by-path/platform-i8042-serio-0-event-kbd |
LINK: /dev/input/by-path/platform-i8042-serio-0-event-kbd |
||
}} |
}} |
||
+ | ここでは {{ic|LINK}} の設定は特定の名前を持つデバイスとマッチしますが、正規表現も可です。 |
||
− | The {{ic|LINK}} configuration will match a device with a specific name, but it will accept also a regex option. |
||
+ | 複数のジョブ設定を組み合わせることで、デフォルトの挙動を設定することができます。いずれの場合も、最初にマッチしたジョブのみが実行されます: |
||
− | This can be combined with multiple job specifications to create a default behavior, in each case only the first matching job is going to be executed: |
||
{{bc| |
{{bc| |
||
120行目: | 119行目: | ||
}} |
}} |
||
− | ==== デバイスを組み合わせる ==== |
+ | ==== 複数のデバイスを組み合わせる ==== |
+ | {{ic|uinput}} ツールは、入力のエミュレーションだけでなく、デバイスの記述を YAML 形式で出力するために使用することもできます: |
||
− | Beside input emulation, the {{ic|uinput}} tool also serves purpose to print a device's description in YAML format: |
||
$ uinput -p -d /dev/input/by-id/my-kbd |
$ uinput -p -d /dev/input/by-id/my-kbd |
||
+ | YAML ファイルは、以下のようにして {{ic|uinput}} に与えることができます: |
||
− | which itself can be fed back to {{ic|uinput}} as: |
||
$ uinput -c my-kbd.yaml |
$ uinput -c my-kbd.yaml |
||
+ | また、デバイスの記述と YAML で書かれた記述を同時に使用することもできます (例えば、キーボードとマウスのイベントを組み合わせることができます): |
||
− | It can also merge device and YAML characteristics, which can be used for instance to combine events coming from keyboard and mouse: |
||
− | + | 例えば、{{ic|CapsLock+Click}} を {{ic|Ctrl+Click}} として使う場合: |
|
$ uinput -p -d /dev/input/by-id/my-kbd -d /dev/input/by-id/my-mouse -c my-extra.yaml |
$ uinput -p -d /dev/input/by-id/my-kbd -d /dev/input/by-id/my-mouse -c my-extra.yaml |
||
138行目: | 137行目: | ||
==== 複数のジョブを処理する ==== |
==== 複数のジョブを処理する ==== |
||
+ | {{ic|mux}} を使うことで、複数のパイプラインを1つにまとめることができます。''muxer'' を先に作成しておく必要があります。作成した muxer は、後にパイプラインの入力や出力として使用できます。YAML 設定ファイルでは、muxer は {{ic|CMD}} キーを使って作成できます: |
||
− | The {{ic|mux}} is used to combine multiple pipelines into a single one. |
||
− | A ''muxer'' needs to be created first, |
||
− | and it can later be used as the input or the output of a given pipeline. |
||
− | In a YAML specification file, the muxer is created using the {{ic|CMD}} key: |
||
{{bc| |
{{bc| |
||
154行目: | 150行目: | ||
}} |
}} |
||
+ | 上記の例では、キーボードが接続された時に、キーボードは捕捉 (grab) され、入力イベントは最初に作成しておいた {{ic|caps2esc}} muxer に送られます。マウスから観測された (捕捉されていない) 入力も、同じ muxer に送られます。マウスのボタンは {{ic|EV_KEY}} イベントを生成するので、{{ic|caps2esc}} はそのイベントを受け入れます。 |
||
− | In the example above, when the keyboard is connected, it's grabbed and its input events are sent to the {{ic|caps2esc}} muxer that was initially created. Observed input (not grabbed) from mouse is also sent to the same muxer. The buttons of the mouse generate {{ic|EV_KEY}} events, so {{ic|caps2esc}} will accept them. |
||
== 参照 == |
== 参照 == |
||
161行目: | 157行目: | ||
* [https://gitlab.com/interception/linux/tools 公式ウェブサイト] |
* [https://gitlab.com/interception/linux/tools 公式ウェブサイト] |
||
* [https://github.com/kmonad/kmonad kmonad] - 高度なキーボードリマッピングツールのデーモン |
* [https://github.com/kmonad/kmonad kmonad] - 高度なキーボードリマッピングツールのデーモン |
||
+ | |||
+ | {{TranslationStatus|interception-tools|2023-08-11|785050}} |
2023年8月11日 (金) 09:50時点における最新版
interception-tools は、キーボード入力のマッピングの制御とカスタマイズをするためのユーティリティのセットです。
interception-tools は、libevdev と libudev(3) を使用することで、他の似たようなツール (xcape、xmodmap) よりも低レベルで動作します。ゆえに interception-tools は、X11、Wayland、そして Linux コンソールの全てでキーボードの挙動をカスタマイズできる数少ない方法の1つとなります。
目次
インストール
interception-tools をインストールしてください。
利用可能なプラグインはたくさんあります:
- interception-caps2esc (
Ctrl
/Esc
でCapsLock
を切り替える) - interception-caps2esc-delay-gitAUR
- interception-caps2esc-nocaps-gitAUR
- interception-dual-function-keys (キーが押されたときの挙動を変更する)
- interception-hideawayAUR
- interception-k2k-gitAUR
- interception-ralt2hyperAUR
- interception-space2metaAUR
- interception-uswitchAUR
- interception-vimproved-gitAUR
- interception-xswitchAUR
設定
interception-tools には、いくつかのコマンドラインツールと1つの systemd サービスが含まれています。
パッケージに含まれている udevmon.service
を起動する場合は、まず先に /etc/interception/udevmon.yaml
に設定を追加しておく必要があります。
仕組み
Interception-tool は libevdev を使用します (libevdev は、このライブラリの wiki によると、本質的には /dev/input/eventX
デバイス用に強化された read(2) です)。
libevdev は、イベントを処理するプロセスとカーネルとの間で動作します。
最もシンプルなシナリオでは、以下のような感じになります:
カーネル | libevdev | evtest
X.Org 入力モジュールの場合、スタックは以下のようになります:
カーネル | libevdev | xf86-input-evdev | X サーバ | X クライアント
Wayland では、スタックは以下のようになります:
カーネル | libevdev | コンポジタ | Wayland クライアント
言い換えると、libevdev
は低レベルであるため、X/Wayland クライアントに関する情報を持ちません。
実用例
Interception-tools では4つのユーティリティが使用できます:
intercept
: デバイスの入力イベントを標準出力にリダイレクトする。mux
: 入力イベントの複数のストリームを結合する。udevmon
: 入力デバイスを監視し、(それに応じて) タスクを開始する。uinput
: 入力イベントを標準入力から仮想デバイスへリダイレクトする。
実行優先度を上げる
このツールはデバイス入力の最も低いレベルで動作するため、udevmon
の実行優先度を上げて持続的に動作するようにしてください:
# nice -n -20 udevmon -c udevmon.yaml > udevmon.log 2> udevmon.err &
シンプルなリダイレクト
イベントを標準出力に (他に何もせずに) リダイレクトする最も単純な方法は:
$ intercept -g DEVNODE | uinput -d DEVNODE
DEVNODE
は実際のデバイスへのパスです (例: /dev/input/by-path/platform-i8042-serio-0-event-kbd
)。
コマンドを挟む
キーイベントと入力との間で何か処理を行うには、その処理を intercept
と uinput
との間にパイプで挟んでください。
例えば、interception-caps2esc プラグインをインストールし、以下のコマンドを実行してみてください:
$ intercept -g DEVNODE | caps2esc | uinput -d DEVNODE
-g
フラグを省略すると、デバイスイベントは単に観測されるだけで、捕捉 (grab) されません (訳注: -g
フラグを付けることにより、そのデバイスに排他的にアクセスできるようになります。そうすることで、uinput
によって作成された新しい仮想デバイスが元のデバイスイベントを処理後のデバイスイベントに完全に置き換えることができます。-g
を付けないと、処理される前の元のデバイスイベントが残ってしまいます。)。
YAML で設定する
先の方法で入力をインターセプトするのは、すぐに最適ではなくなるかもしれません。そのような場合、udevmon
が役に立ちます。
udevmon は、ジョブ (デフォルトでは sh コマンド) のリストを含む YAML 設定ファイルを読み込み、それらを (適切な時に) 実行します。
デバイスが記述とマッチする場合にジョブを実行する例:
$ udevmon -c caps2esc.conf.yml
- JOB: intercept -g DEVNODE | caps2esc | uinput -d DEVNODE DEVICE: LINK: /dev/input/by-path/platform-i8042-serio-0-event-kbd
ここでは LINK
の設定は特定の名前を持つデバイスとマッチしますが、正規表現も可です。
複数のジョブ設定を組み合わせることで、デフォルトの挙動を設定することができます。いずれの場合も、最初にマッチしたジョブのみが実行されます:
- JOB: intercept -g DEVNODE | caps2esc -m 2 | uinput -d DEVNODE DEVICE: LINK: /dev/input/by-id/usb-SEMITEK_USB-HID_Gaming_Keyboard_SN0000000001-event-kbd - JOB: intercept -g DEVNODE | caps2esc | uinput -d DEVNODE DEVICE: EVENTS: EV_KEY: [[KEY_CAPSLOCK, KEY_ESC]] LINK: .*-event-kbd
複数のデバイスを組み合わせる
uinput
ツールは、入力のエミュレーションだけでなく、デバイスの記述を YAML 形式で出力するために使用することもできます:
$ uinput -p -d /dev/input/by-id/my-kbd
YAML ファイルは、以下のようにして uinput
に与えることができます:
$ uinput -c my-kbd.yaml
また、デバイスの記述と YAML で書かれた記述を同時に使用することもできます (例えば、キーボードとマウスのイベントを組み合わせることができます):
例えば、CapsLock+Click
を Ctrl+Click
として使う場合:
$ uinput -p -d /dev/input/by-id/my-kbd -d /dev/input/by-id/my-mouse -c my-extra.yaml
複数のジョブを処理する
mux
を使うことで、複数のパイプラインを1つにまとめることができます。muxer を先に作成しておく必要があります。作成した muxer は、後にパイプラインの入力や出力として使用できます。YAML 設定ファイルでは、muxer は CMD
キーを使って作成できます:
- CMD: mux -c caps2esc - JOB: mux -i caps2esc | caps2esc | uinput -c /etc/interception/gaming-keyboard.yaml - JOB: intercept -g DEVNODE | mux -o caps2esc DEVICE: LINK: /dev/input/by-id/my-kbd - JOB: intercept DEVNODE | mux -o caps2esc DEVICE: LINK: /dev/input/by-id/my-mouse
上記の例では、キーボードが接続された時に、キーボードは捕捉 (grab) され、入力イベントは最初に作成しておいた caps2esc
muxer に送られます。マウスから観測された (捕捉されていない) 入力も、同じ muxer に送られます。マウスのボタンは EV_KEY
イベントを生成するので、caps2esc
はそのイベントを受け入れます。
参照
- 入力リマップユーティリティ - 似たようなソフトウェアのリストがいくつかあります。
- 公式ウェブサイト
- kmonad - 高度なキーボードリマッピングツールのデーモン