Se suponía que USB acabaría con el zoológico de cables del PC, pero los dispositivos de interfaz humana tenían otro problema: cada ratón, teclado, tableta o mando de juego podía exponer un conjunto distinto de botones, ejes, ruedas y LED. La respuesta simple era un controlador para cada familia de periféricos.

El movimiento ingenioso de HID fue el descriptor de informe. El propio dispositivo envía un bytecode compacto que indica qué informes puede intercambiar y qué significa cada campo. La definición de clase pretendía explícitamente ser compacta, extensible y autodescriptiva.

Eso abarató la novedad. Un host podía usar un único controlador de clase HID para muchos dispositivos, mientras que los fabricantes podían añadir controles sin tener que convencer primero a cada proveedor de sistema operativo de que enviara un nuevo controlador específico para ese modelo.

Hacer que el dispositivo describa sus controles

El descriptor trasladó el conocimiento específico del dispositivo del software del host al periférico.

Los campos desconocidos podían omitirse, de modo que el formato toleraba dispositivos futuros.

Las tablas de uso dieron significados comunes a los controles sin congelar los diseños físicos.

Cuando la variedad de hardware es interminable, estandarice el lenguaje de descripción en lugar de cada forma de producto. Un analizador genérico puede absorber la variación que un catálogo de controladores no puede.

HID escapó del propio USB: la documentación de Linux señala que HID ahora funciona sobre transportes USB, I2C y Bluetooth. La misma idea sigue explicando por qué teclados, dispositivos señaladores y mandos poco habituales a menudo se vuelven utilizables en cuanto se enumeran.

CONSULTA LAS PRUEBAS

Las fuentes

  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