L'USB HID a permis à des périphériques d'entrée insolites de fonctionner en se décrivant eux-mêmes

L'USB était censé mettre fin au zoo de câbles du PC, mais les périphériques d'interface humaine avaient un autre problème : chaque souris, clavier, tablette ou manette de jeu pouvait exposer un ensemble différent de boutons, d'axes, de molettes et de LED. La réponse naïve consistait à fournir un pilote pour chaque famille de périphériques.

L'astuce de HID fut le descripteur de rapport. Le périphérique lui-même envoie un bytecode compact qui indique quels rapports il peut échanger et ce que signifie chaque champ. La définition de classe visait explicitement à être compacte, extensible et auto-descriptive.

Cela rendait l'innovation peu coûteuse. Un hôte pouvait utiliser un seul pilote de classe HID pour de nombreux périphériques, tandis que les fabricants pouvaient ajouter des commandes sans devoir d'abord convaincre chaque fournisseur de système d'exploitation de livrer un nouveau pilote spécifique à un modèle.

Faire décrire ses commandes par le périphérique

Le descripteur a déplacé la connaissance spécifique au périphérique du logiciel hôte vers le périphérique lui-même.

Les champs inconnus pouvaient être ignorés, de sorte que le format tolérait les périphériques à venir.

Les tables d'usage donnaient des significations communes aux commandes sans figer les conceptions physiques.

Lorsque la variété matérielle est sans fin, il faut standardiser le langage de description plutôt que chaque forme de produit. Un analyseur générique peut absorber une variation qu'un catalogue de pilotes ne peut pas.

HID s'est affranchi de l'USB lui-même : la documentation Linux note que HID fonctionne désormais sur les transports USB, I2C et Bluetooth. La même idée explique encore pourquoi des claviers, dispositifs de pointage et manettes inhabituels deviennent souvent utilisables dès qu'ils s'énumèrent.