Débogage USB HID Boot Protocol vs Report Protocol

Comment déboguer la commutation USB HID Boot Protocol et Report Protocol, requêtes SetProtocol, mode BIOS clavier, report IDs, touches manquantes et compatibilité firmware HID.

hid boot protocol, report protocol, setprotocol, clavier usb, mode bios, report id, diagnostic usb

Les claviers et souris USB HID peuvent utiliser Boot Protocol ou Report Protocol. Les utilisateurs cherchent « HID Boot Protocol », « HID Report Protocol », « USB keyboard BIOS mode », « SetProtocol HID », « keyboard works in BIOS but not OS » ou « HID report ID missing keys » quand l'entrée marche dans un environnement mais échoue dans un autre.

Bus Scope est utile car l'hôte peut envoyer des requêtes de classe HID qui changent la façon dont le périphérique formate les rapports. Si le firmware ignore SetProtocol ou envoie le mauvais format de rapport, des touches peuvent disparaître même si le périphérique s'énumère correctement.

Boot Protocol

Boot Protocol est un format HID simplifié utilisé par le BIOS, UEFI, les environnements de pré-boot et les piles hôte simples. Il permet à des claviers et souris basiques de marcher avant qu'un parser HID complet ne soit disponible.

Symptômes impliquant Boot Protocol :

  • Clavier marche dans le BIOS mais échoue dans l'OS.
  • Clavier marche dans l'OS mais pas dans le menu de boot.
  • Touches spéciales disparaissent en mode pré-boot.
  • Souris marche seulement après chargement de l'OS.
  • Le firmware envoie des report IDs quand le rapport boot n'en attend pas.

La question diagnostique est : quel protocole l'hôte a-t-il sélectionné ?

Report Protocol

Report Protocol utilise le HID report descriptor. Il supporte des dispositions plus riches, report IDs, rapports vendor, touches média, capteurs et comportement composite.

Si l'hôte passe en Report Protocol mais que le périphérique continue d'envoyer des rapports Boot, l'OS peut parser l'entrée incorrectement. Si l'hôte demande Boot Protocol mais que le périphérique envoie Report Protocol, le BIOS peut ignorer les rapports.

Requête SetProtocol

La requête de classe HID SetProtocol peut basculer entre Boot Protocol et Report Protocol pour les périphériques supportés.

Preuves à collecter :

  • Descripteur d'interface HID.
  • Valeurs Boot subclass et protocol.
  • Report descriptor.
  • Requête SetProtocol.
  • Valeur de protocole sélectionnée par l'hôte.
  • Octets de rapport interrupt IN avant et après le switch.

Bus Scope peut rendre cette séquence visible.

Report IDs et touches manquantes

Report Protocol peut utiliser des report IDs. Boot Protocol attend souvent des rapports de taille fixe sans préfixe de report ID.

Bugs firmware fréquents :

  • Le périphérique inclut le report ID en Boot Protocol.
  • Le périphérique omet le report ID en Report Protocol.
  • Le périphérique change la taille du rapport mais le descripteur ne suit pas.
  • Les touches média sont uniquement dans un rapport secondaire.
  • Le rapport NKRO est envoyé avant que l'hôte ne l'active.
  • Le clavier envoie un rapport vendor sur l'endpoint clavier.

Ces bugs créent des expressions comme « USB keyboard missing keys » et « HID report ID wrong ».

Comportement BIOS vs système d'exploitation

Les environnements BIOS et UEFI sont généralement plus stricts et plus simples que les OS complets. Un clavier peut paraître correct sur Windows ou Linux mais échouer avant le boot.

Comparaison utile :

  • Capture pendant le pré-boot si possible avec un analyseur externe.
  • Capture après chargement de l'OS.
  • Comparez le comportement de SetProtocol.
  • Comparez le format de payload des rapports.
  • Vérifiez si le périphérique reset entre environnements.

Même si la capture pré-boot est difficile, la preuve SetProtocol côté OS peut révéler les hypothèses du firmware.

Checklist de débogage

Suivez ce processus :

  1. Capturez l'énumération.
  2. Inspectez la subclass et le protocol de l'interface HID.
  3. Inspectez le HID report descriptor.
  4. Trouvez les requêtes SetProtocol.
  5. Décodez le protocole sélectionné.
  6. Comparez les rapports interrupt IN avant et après.
  7. Vérifiez l'usage du report ID.
  8. Testez touches normales et touches média.
  9. Comparez le comportement BIOS, bootloader, Windows et Linux.
  10. Conservez ensemble les octets de descripteurs et de rapports.

Diagnostic final

Les échecs HID Boot Protocol et Report Protocol sont des problèmes de négociation de format de rapport. Le périphérique peut s'énumérer correctement tout en envoyant des rapports dans le mauvais format de protocole.

Bus Scope aide à prouver si des touches manquantes, échecs d'entrée en BIOS ou problèmes de compatibilité HID viennent de la gestion SetProtocol, des report IDs, d'un décalage de descripteurs ou du formatage des rapports firmware.