USB sollte den Kabelzoo des PCs beenden, doch Human-Interface-Geräte hatten ein anderes Problem: Jede Maus, Tastatur, jedes Tablet oder jeder Gamecontroller konnte einen anderen Satz von Tasten, Achsen, Rädern und LEDs bereitstellen. Die einfältige Antwort war ein Treiber für jede Peripheriefamilie.
Der clevere Schachzug von HID war der Report-Deskriptor. Das Gerät selbst sendet einen kompakten Bytecode, der angibt, welche Reports es austauschen kann und was jedes Feld bedeutet. Die Klassendefinition zielte ausdrücklich darauf ab, kompakt, erweiterbar und selbstbeschreibend zu sein.
Das machte Neuartiges billig. Ein Host konnte einen einzigen HID-Klassentreiber für viele Geräte verwenden, während Hersteller Bedienelemente hinzufügen konnten, ohne zuerst jeden Betriebssystemanbieter davon zu überzeugen, einen neuen modellspezifischen Treiber auszuliefern.
Lass das Gerät seine Bedienelemente beschreiben
Der Deskriptor verlagerte gerätespezifisches Wissen von der Host-Software in die Peripherie.
Unbekannte Felder konnten übersprungen werden, sodass das Format künftige Geräte tolerierte.
Usage-Tabellen gaben Bedienelementen gemeinsame Bedeutungen, ohne physische Designs festzuschreiben.
Wenn die Hardwarevielfalt endlos ist, standardisiere die Beschreibungssprache statt jeder Produktform. Ein generischer Parser kann Variation aufnehmen, die ein Treiberkatalog nicht bewältigen kann.
HID entkam USB selbst: Die Linux-Dokumentation merkt an, dass HID heute über USB-, I2C- und Bluetooth-Transporte funktioniert. Dieselbe Idee erklärt noch immer, warum ungewöhnliche Tastaturen, Zeigegeräte und Controller oft nutzbar werden, sobald sie sich aufzählen.
DEN BELEGEN FOLGEN
Die Quellen
- Device Class Definition for HID 1.11 USB Implementers Forum · usb.org
- Introduction to HID report descriptors The Linux Kernel documentation · kernel.org