O USB HID fez dispositivos de entrada incomuns funcionarem ao se descreverem

Esperava-se que o USB acabasse com o zoológico de cabos do PC, mas os dispositivos de interface humana tinham outro problema: cada mouse, teclado, mesa digitalizadora ou controle de jogo podia expor um conjunto diferente de botões, eixos, rodas e LEDs. A resposta ingênua era um driver para cada família de periféricos.

O truque inteligente do HID foi o descritor de relatório. O próprio dispositivo envia um bytecode compacto que diz quais relatórios pode trocar e o que cada campo significa. A definição da classe visava explicitamente ser compacta, extensível e autodescritiva.

Isso tornou a novidade barata. Um host podia usar um único driver da classe HID para muitos dispositivos, enquanto os fabricantes podiam adicionar controles sem primeiro convencer todos os fornecedores de sistemas operacionais a enviar um novo driver específico para o modelo.

Fazer o dispositivo descrever seus controles

O descritor moveu o conhecimento específico do dispositivo do software do host para o periférico.

Campos desconhecidos podiam ser ignorados, então o formato tolerava dispositivos futuros.

As tabelas de uso deram significados comuns aos controles sem congelar os projetos físicos.

Quando a variedade de hardware é infinita, padronize a linguagem de descrição em vez de cada formato de produto. Um analisador genérico pode absorver variações que um catálogo de drivers não consegue.

O HID escapou do próprio USB: a documentação do Linux observa que o HID agora funciona por transportes USB, I2C e Bluetooth. A mesma ideia ainda explica por que teclados, dispositivos apontadores e controles incomuns muitas vezes se tornam utilizáveis assim que são enumerados.