USBはPCのケーブル動物園を終わらせるはずだったが、ヒューマンインターフェースデバイスには別の問題があった。マウス、キーボード、タブレット、ゲームコントローラーのそれぞれが、異なるボタン、軸、ホイール、LEDの組み合わせを公開し得たのだ。愚直な答えは、周辺機器の系統ごとにドライバーを用意することだった。

HIDの賢い一手はレポート記述子だった。デバイス自身が、どのレポートをやり取りでき、各フィールドが何を意味するかを述べるコンパクトなバイトコードを送る。クラス定義は、コンパクトで拡張可能かつ自己記述的であることを明示的に目指していた。

これにより、新規性のコストは安くなった。ホストは多数のデバイスに対して単一のHIDクラスドライバーを使え、メーカーは各OSベンダーに機種固有の新しいドライバーを同梱させるよう説得することなく、コントロールを追加できた。

デバイスに自身のコントロールを記述させる

記述子は、デバイス固有の知識をホストソフトウェアから周辺機器へ移した。

未知のフィールドはスキップできたため、この形式は将来のデバイスを許容した。

使用法テーブルは、物理設計を固定することなく、コントロールに共通の意味を与えた。

ハードウェアの多様性が際限ないときは、あらゆる製品形状ではなく、記述言語を標準化せよ。汎用パーサーは、ドライバーカタログでは吸収できないばらつきを吸収できる。

HIDはUSB自体からも脱出した。Linuxのドキュメントは、HIDが現在USB、I2C、Bluetoothの各トランスポート上で動作すると記している。同じ考え方は、風変わりなキーボード、ポインティングデバイス、コントローラーが列挙されるとすぐに使えるようになることが多い理由を、今も説明している。

出典をたどる

出典

  1. Device Class Definition for HID 1.11 USB Implementers Forum · usb.org
  2. Introduction to HID report descriptors The Linux Kernel documentation · kernel.org