Input Hotplug Guide
X.orgの新しい入力デバイスホットプラグ機構についての説明がDebian WikiのInputHotplugGuideにまとめられている。ここんところ忙しくてまだsidにしてないので使ってないけどなー。適当に超訳してみた。
はじめに
X.org X サーバは最近、入力サブシステムに重要な改良を施しました。最も重要なのは入力ホットプラグ (input-hotplugging, 以降 i-h) で、X サーバにデフォルトでないキーマップを xorg.conf に指定しなくても正しい設定で機能するというものです。 この新しいシステムは hal および dbus に基づいているので、外部ツールのようなものが必要になるのではないかと懸念される人もいらっしゃるでしょう。 X サーバはそういったプログラムを使うことなしにこれまで動作してきたので、これはもっともな疑問です。 このドキュメントの最初のパートでは、新しい入力システムの原理、どのような問題を解決するか、どのようにそれが機能するか、について説明したいと思います。 なによりも重要なメッセージは、新しい入力サブシステムは、その機能性を倍加させるというより、ホスト OS に基づいて構築されており、ハードウェアに問い合わせ、相互作用するための標準化されたインターフェイスを使うことで OS を単純化させられるということです。 このドキュメントの 2 番目のパートは、必要に応じてどのようにシステムを設定するかを説明する HOWTO です。
原理
X.org の長期的目標
X.org プロジェクトは XFree86 プロジェクトから連綿と続いてきたコードベースを受け継ぎました。 最大の制約は、私たちが今日亨受しているフリーソフトウェア環境が提供されていないような、多種多様に異なる UNIX 間での絶対的な移植性が過去に必要とされていたことです。 そのため、X は自身で、システムバスの走査からハードウェアの駆動まで、何でもこなさなければなりませんでした。 要するに、これは OS の上に乗っかった OS だったのです。
設立以来の X.org の最重要目標の 1 つは、この類の振舞いを止めることで X を今風なものに引き上げることでした。 今日私たちはカーネルから起こされた完全にオープンな OS を手にしており、古い UNIX は死あるいは死に瀕していることから、このビジョンにのっとって多くの段階を踏んできました。 古いモノリシックな X のコードベースは適切な形に分割され、その特別なビルドシステムもほぼ標準の autotools に移行しました。 加えて、X は古い /usr/X11R6 ディレクトリを去って、ほかの通常のソフトウェアピース同様に FHS の世界に入りました。 X サーバの特別なローダシステム (そう、自前のローダを持っていたのです!) は、標準化された ELF 形式で置き換えることで、スクラップにされました。 PCI バス操作コードは削除され、今ではサーバは、OS に PCI デバイスを照会するのに外部の libpciaccess を利用します。 linux では、これは単に標準化インターフェイスの /sys を見るだけです。
これらの開発のすべては、X を、偏執的な独立独行の部外者ではなく、ホスト OS の良き市民として振る舞うようにするという目標に沿っています。新規の移行は、Kernel Mode Setting (KMS) および GEM メモリマネージャという形でビデオドライバの大部分をカーネルに移動することで現在のシステムの公開性のメリットを活用すべく実際始められたのです。
基本入力
前述したことから推測されるとおり、古い入力ドライバ (keyboard/kbd、mouse、その他) は、実際にハードウェアを駆動するためにそれについての完全な知識を持っていなければなりませんでした。 自前でこの作業を行っていたので、必要なサポートを提供するのにホスト OS を当てにする必要はありませんでした。 しかし、ホスト OS がフリーで提供する事柄を亨受できず、ホスト OS 上で利用可能な機能を重複して実装しなければならなかったのです。
evdev ドライバはこれを変える最初のステップでした。 evdev は一般の I/O を操作するためのフレームワークです。 このフレームワークはカーネルが特定のデバイスの詳細を扱うようにし、またユーザスペースのプログラムがそれとインターフェイスを持つことができるようにします。 X サーバが evdev ドライバを使うと、すべての実ハードウェアの操作がその属するカーネルに事実上移動します。 カーネルは、マウスボタンやホイール機能のような事象についての情報を提供することもでき、最適なドライバのものと同等の柔軟性を X サーバに与えます。 これは、大きく簡易化、保守容易化された X 側でのドライバを提供するので、 明確に責任範囲が分割され、X サーバが OS の良き市民となります。 総合的に言えば、evdev を使うことは、システムの複雑さを軽減することにつながります。 これらの利点から、現在の Linux 上での X サーバのデフォルトは、evdev を使います。 そのため、evdev でキーマップを提供するという変更は、xbindkeys や xmodmap を使って作成したカスタムマッピングを使っている人にとって少々不安をかきたてたようです。 この場合に必要なのは、単に新しいキーコードに再マップすることだけです。 無論、これは私たちが予知可能な未来において再び起こるかもしれない問題の類ではありませんが、evdev に切り替えることで真の利益を得るために、10年に一度払うだけの価値はあります。
hal、dbus、console-setup
この時点で、システムにいくつかの大きな改善はなされましたが、その他のいろいろな問題はまだ残っています。 まず、真っ先に挙げられるのが、デフォルトの 'us' マップを使いたくないときキーマップを設定するのに xorg.conf がまだ絶対に必要とされていることです。 Debian は、キーマップをユーザに尋ねてそれを適切に設定するための大きなシェルスクリプトを持ち続けなければなりません。 この情報は、キーマップについての別個の設定を持つコンソールとも重複します。 2 つが同期しないとしたら、これは明らかに問題を引き起こします。
加えて、ホットプラグは十分にサポートされているとは言い難いものでした。 Linux カーネルは、すべてのデバイスイベントを単一のデバイスインターフェイスに多重化することでホットプラグを透過的に管理できます。 これは多くの人にとって十分よく動作していたので、これが機能しないというのはどうにも不愉快なことでした。 X サーバはカーネルがその裏で何をしているかについてわからなかったので、結局デバイス単位の設定を管理することはできませんでした。 そのため、デフォルトに適合しないか xorg.conf でまだ設定していないデバイスがホットプラグされると、前述のような同じ問題にまい戻らされました。
これらの問題の両方を解決するために、1 つの概念的解決がありました: それは、X サーバが、デバイスが何か、どのように固有の扱いをすべきかをホスト OS に尋ねることです。 たとえばデバイスがマウスなら、拡張ボタンはどうなっているでしょうか? デバイスがキーボードなら、キーマップには何を使うべきでしょうか? サーバが情報を取得できるなら、それ自身で設定を持つ必要はもはや不要です。 この情報を持つ単一の場所を持ち、すべてのアプリケーションが X サーバと同じやり方でそれに照会できるので、これはシステム全体の複雑性を軽減します。
Linux でこの問題を取り扱う方法が、hal を使うことです。 hal は多くの人にとっては神秘の代物ですが、その概念はとても単純です。 hal は udev 経由でのデバイスの作成/削除のためにカーネルを監視します。 イベントを検出すると、関係するイベントを dbus 経由で送出します。 X サーバは、現在検出されているすべての入力デバイスの一覧を取得するために、起動時に dbus 経由で hal に照会することができます。 hal は、固有のデバイス単位のプロパティをエンコードした一連の xml ファイル (.fdi) で構成されたデータベースから成る追加のプロパティを持っています。 そのため、特定のデバイス情報のために不明瞭な C コードを編集する代わりに、人間が読める形式で記述され、hal を各ユーザにぴったりくっつけることができます。 このもっとも重要な部分は、この情報は xorg.conf にある必要がなく、つまり誰かがインストール時に xorg.conf を書くたびに毎回再入力することが不要であるということです。 サーバはただ暗黙に hal 経由でシステムから情報を取得します。 加えて hal は、xorg.conf 形式ではできない、すべてのマウスに何かさせるといったグループ設定も可能です。 サーバは、入力ホットプラグが稼働できるよう、dbus に接続したままにして hal を監視し続けることもできます。
最後のひとかけは、console-setup です。このドキュメントの目的として、console-setup はシステムワイドなキーマップ設定の面倒を見ます。 各ユーザはコンソールを持ちますが、すべてのユーザが X を使っているとは限らず、この責任を担当すべき適切なところは console-setup です。 console-setup は現在、インストール時に xorg.conf を読んで、もし存在するならそれをシステムワイドなキーマップの設定に使います。 これは過去の設定が移行で失われないことを保証します。 console-setup はそれから hal にキーマップが何かを伝え、これによって hal は X サーバからの照会を受けたときにそれを伝えることができます。 これで、xorg.conf にキーマップを含める必要がなくなり、システム全体の単一の場所 (/etc/default/console-setup) で設定するだけとなって、X サーバがほかのアプリケーションと同様に単にそれを使うようになります。
まとめ
入力サブシステムの改良の目標は、標準化された OS サービスを利用して Xorg コードベースと OS の双方の複雑さを軽減すると同時に、重要な新しい機能性を提供することでした。 これらの目標の両方は達成されました。 現在では、コンソールと X で別々に設定する代わりに、システムワイドなキーマップを設定する単一の場所があります。 加えて、デバイスのホットプラグは完全にサポートされ、X サーバはそれを完全に亨受できています。 最後に、ドライバごとの C のコードや独自の xorg.conf ファイルでの多数の情報を再エンコードする代わりに、X サーバは hal のデータベースで提供されるデバイス固有のプロパティを利用できます。 X.org と X Strike Force は、これらが、過去の低い機能性や不自由さを乗り越えて進み続けるために X が必要としていた、大きな進歩を表していると信じています。 以降のセクションは、あなたがこのシステムを最良に使うのを助けるべく設計されました。
HOWTO
キーボード
アップグレード時に、hal および console-setup が xserver-xorg の依存/推奨によって持ち込まれます。
console-setup は、既存の xorg.conf からキーボードレイアウト情報を集めます。そのため、/etc/default/console-setup の以下のような行を得られるはずです。 これを手で修正してもかまいません。
$ grep -C 3 -i xkb /etc/default/console-setup
# The following variables describe your keyboard and can have the same
# values as the XkbModel, XkbLayout, XkbVariant and XkbOptions options
# in /etc/X11/xorg.conf.
XKBMODEL="pc105"
XKBLAYOUT="fr"
XKBVARIANT="latin9"
XKBOPTIONS="lv3:ralt_switch"
console-setup の用意ができると、hal はそこから情報を集めます。アップグレードされていないときには、hal の再起動 (/etc/init.d/hal restart) が必要かもしれません。 その後 lshal を実行すると、正しいキーボードレイアウトを報告するはずです。
$ lshal | grep xkb
input.xkb.layout = 'fr' (string)
input.xkb.model = 'pc105' (string)
input.xkb.options = 'lv3:ralt_switch' (string)
input.xkb.rules = 'base' (string)
入力デバイスが検出されると、X サーバは hal から情報を取得します。 /var/log/Xorg.0.log に次のように示されます:
(II) config/hal: Adding input device Dell Dell USB Keyboard
(**) Dell Dell USB Keyboard: always reports core events
(**) Dell Dell USB Keyboard: Device: "/dev/input/event9"
(II) Dell Dell USB Keyboard: Found keys
(II) Dell Dell USB Keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device "Dell Dell USB Keyboard" (type: KEYBOARD)
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "pc105"
(**) Option "xkb_layout" "fr"
(**) Option "xkb_variant" "latin9"
(**) Option "xkb_options" "lv3:ralt_switch"
別のレイアウトに切り替えるために、/etc/hal/fdi/policy/ への新しい *.fdi ファイルとしていくつかの上書きルールを追加できます。たとえば、ドイツ語レイアウトを取得するには次のようにします:
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
<match key="info.capabilities" contains="input.keys">
<-- Enforce XkbLayout=de and XkbVariant empty -->
<merge key="input.xkb.layout" type="string">de</merge>
<merge key="input.xkb.variant" type="string" />
</match>
</device>
</deviceinfo>
異なるレイアウトの異なるキーボードを保有しているなら、そのうちの 1 つにレイアウトを変更するためだけのいくつかの "マッチ" ルールを追加する必要があるかもしれません。 fdi ファイルを追加 / 変更したあとに hal を再起動することを忘れないでください!
マウス
マウスについてはずっと簡単で、すべきことは何もなく、evdev が自動でロードされます。
タッチパッド
synaptics タッチパッドを使っているのなら、マウスとして利用できるはずです。ただし、hal はタッチパッド能力があることも報告します:
$ lshal
[...]
udi = '/org/freedesktop/Hal/devices/platform_i8042_i8042_AUX_port_logicaldev_input_0'
[...]
info.capabilities = {'input', 'input.mouse', 'input.touchpad', 'access_control'} (string list)
よって、xserver-xorg-input-synaptics がインストールされていると、(/usr/share/hal/fdi/policy/20thirdparty/11-x11-synaptics.fdi ファイルのおかげで) hal に evdev の代わりに synaptics ドライバをロードするよう伝えられます。
HAL を無効にする
xorg.conf の ServerFlags セクションで AllowEmptyInput および AutoAddDevices を off にすると、そうなります。
デバイスを無視する
Xorg があなたの入力デバイスの何かを使おうとするのを望まない場合、かつては xorg.conf にそれについて記述しないというだけで済んでいました。今では、hal がサーバにすべてのデバイスを伝え、それらすべてがデフォルトで有効になります。これを無効にするには、次のようにします:
<match key="info.product" contains="myname">
<remove key="input.x11_driver"/>
</match>
"myname" を何にするかを調べるには、lshal を使います。
FDI ファイルの記述
ドキュメントは http://cgit.freedesktop.org/xorg/xserver/plain/config/x11-input.fdi を参照してください。hal パッケージの /usr/share/doc/hal/examples/10-x11-input.fdi にある例も利用可能です。
参照
Peter Hutterer の blog、特に この投稿とこの投稿を参照してください。
これと類似のドキュメントはArch linuxのこのページを参照してください。
madduck は、どのようにデフォルトのオプション、レイアウト、バリアントを超えて XKB を拡張するかについての簡単なライトアップを保有しています。
著者
このドキュメントの寄稿には、Julien Cristau、BriceGoglin、Peter Hutterer、DavidNusinow がかかわりました。
XStrikeForce/InputHotplugGuide (最終更新日時 2009-04-20 04:20:44 更新者 KenBloom)
[翻訳: Kenshi Muto, kmuto at debian.org]
引用元: KeN's GNU/Linux Diary,
"http://kmuto.jp/d/index.cgi/debian/#input-hotplug-guide"
