「Interception-tools」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
細 (余分な空白を削除)
(→‎設定: 翻訳)
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|Configuration files found on {{ic|/etc/interception/udevmon.d/}} are read first, and fallbacks to {{ic|/etc/interception/udevmon.yaml}}.}}
 +
{{Note|{{ic|/etc/interception/udevmon.d/}} 内の設定ファイルがまず先に読み込まれ、その後に {{ic|/etc/interception/udevmon.yaml}} にフォールバックします。}}
   
 
=== 仕組み ===
  
=== 仕組み ===
   
−
Interception-tool makes use of ''libevdev'', which according to its wiki is essentially a {{man|2|read}} on steroids for {{ic|/dev/input/eventX}} devices.
 +
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:
  
   
−
kernel | libevdev | evtest
 +
カーネル | libevdev | evtest
   
  +
X.Org 入力モジュールの場合、スタックは以下のようになります:
−
For X.Org input modules, the stack would look like this:
  
   
−
kernel | libevdev | xf86-input-evdev | X server | X client
 +
カーネル | libevdev | xf86-input-evdev | X サーバ | X クライアント
   
  +
Wayland では、スタックは以下のようになります:
−
For Wayland, the stack would look like this:
  
   
−
kernel | libevdev | Compositor | Wayland client
 +
カーネル | 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 makes 4 utilities available:
+
Interception-tools では4つのユーティリティが使用できます:
   
  +
* {{ic|intercept}}: デバイスの入力イベントを標準出力にリダイレクトします。
−
* {{ic|intercept}}: redirect device input events to stdout,
 
  +
* {{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|The {{ic|udevmon}} systemd service runs with {{ic|1=Nice=-20}}.}}
 +
{{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''
   
−
where {{ic|''DEVNODE''}} is the path to the actual device: e.g. {{ic|/dev/input/by-path/platform-i8042-serio-0-event-kbd}}.
 +
{{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}}.
  
   
−
E.g. with the {{Pkg|interception-caps2esc}} plugin installed:
 +
例えば、{{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:
  
   
−
e.g. instance {{ic|CapsLock+Click}} as {{ic|Ctrl+Click}}
 +
例えば、{{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つにまとめることができます。
−
The {{ic|mux}} is used to combine multiple pipelines into a single one.
  
  +
''muxer'' を先に作成しておく必要があります。
−
A ''muxer'' needs to be created first,
  
  +
作成した muxer は、後にパイプラインの入力や出力として使用できます。
−
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:
 +
YAML 設定ファイルでは、muxer は {{ic|CMD}} キーを使って作成できます:
   
 
{{bc|
  
{{bc|
154行目: 153行目:
 
}}
  
}}
   
  +
上記の例では、キーボードが接続された時に、キーボードは捕捉 (grab) され、入力イベントは最初に作成しておいた {{ic|caps2esc}} muxer に送られます。マウスから観測された (捕捉されていない) 入力も、同じ muxer に送られます (訳注: "捕捉 (grab)" の意味は、[[#コマンドを挟む]] セクションの訳注を見てください)。マウスのボタンは {{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.
  
   
 
== 参照 ==
  
== 参照 ==

2023年8月11日 (金) 09:40時点における版

関連記事

interception-tools は、キーボード入力のマッピングの制御とカスタマイズをするためのユーティリティのセットです。

interception-tools は、libevdev と libudev(3) を使用することで、他の似たようなツール (xcape、xmodmap) よりも低レベルで動作します。ゆえに interception-tools は、X11、Wayland、そして Linux コンソールの全てでキーボードの挙動をカスタマイズできる数少ない方法の1つとなります。

インストール

interception-tools をインストールしてください。

利用可能なプラグインはたくさんあります:

設定

interception-tools には、いくつかのコマンドラインツールと1つの systemd サービスが含まれています。

パッケージに含まれている udevmon.service を起動する場合は、まず先に /etc/interception/udevmon.yaml に設定を追加しておく必要があります。

ノート: /etc/interception/udevmon.d/ 内の設定ファイルがまず先に読み込まれ、その後に /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 &
ヒント: udevmon systemd サービスは Nice=-20 で実行されます。

シンプルなリダイレクト

イベントを標準出力に (他に何もせずに) リダイレクトする最も単純な方法は: 

$ 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 に送られます (訳注: "捕捉 (grab)" の意味は、#コマンドを挟む セクションの訳注を見てください)。マウスのボタンは EV_KEY イベントを生成するので、caps2esc はそのイベントを受け入れます。

参照

「https://wiki.archlinux.jp/index.php?title=Interception-tools&oldid=33268」から取得