Latence d'entrée USB HID et rapports manqués : débogage claviers, manettes, scanners et HID personnalisés

Les problèmes USB HID sont souvent décrits en langage utilisateur: "latence du clavier, touches manquées, double entrée, pertes de scanner de codes-barres, délai de manette, pédale qui ne répond pas, ou périphérique HID personnalisé qui envoie des rapports mais que l'application ne reçoit jamais. Des termes comme « USB HID input lag », « missed HID reports », « HID interrupt endpoint delay », « keyboard repeated keys USB » et « gamepad latency USB capture » pointent tous vers le même besoin d'ingénierie : inspecter le flux de rapport HID, pas seulement l'événement applicatif." Les périphériques HID utilisent généralement des endpoints interrupt. Cela ne signifie pas « interruption hardware » au sens desktop ; cela signifie que l'hôte interroge l'endpoint à un intervalle défini. Si les rapports sont mal formés, retardés, trop fréquents, trop gros, ou mal décrits, l'application peut voir du lag ou des entrées manquantes.

Bus Scope aide car le diagnostic HID a besoin ensemble des preuves de descripteur, endpoint, polling et rapport.

Le descripteur de rapport HID compte

Le descripteur de rapport HID définit ce que les rapports signifient. Il décrit les usages, tailles de rapport, comptes de rapport, plages logiques, report IDs et rapports input/output/feature.

Si le descripteur ne correspond pas aux octets réellement envoyés par le périphérique, les symptômes peuvent être étranges :

• L'application ne voit aucune entrée.
• Certains boutons marchent mais d'autres non.
• Les axes sautent ou saturent.
• Les touches du clavier se répètent.
• Report ID attendu mais pas envoyé.
• Longueur de rapport différente du descripteur.
• L'hôte rejette ou ignore les rapports.

Le périphérique peut envoyer des octets, mais l'hôte les interprète incorrectement.

Intervalle de polling de l'endpoint interrupt

Les endpoints HID interrupt IN incluent un intervalle de polling. Un périphérique low-speed ou full-speed peut être pollé différemment d'un périphérique high-speed. Si l'intervalle de polling est trop lent pour l'usage visé, la latence d'entrée est inscrite dans la configuration du périphérique.

Pour une manette ou un périphérique de contrôle temps réel, l'intervalle de rapport compte. Pour un scanner de codes-barres, des rapports occasionnels peuvent suffire, mais le framing des rapports doit être fiable.

Inspectez les descripteurs d'endpoint :

• Adresse de l'endpoint
• Type de transfert interrupt
• Taille de paquet max
• Intervalle de polling
• Vitesse du périphérique

Ne devinez pas la latence à partir de l'UI applicative seule.

Rapports manqués vs événements applicatifs manqués

Un rapport peut être manquant à plusieurs couches :

• Le firmware du périphérique ne l'a jamais envoyé.
• Le transfert USB a échoué.
• L'hôte a pollé trop lentement.
• Le rapport a été envoyé mais mal formé.
• Le pilote l'a interprété autrement.
• L'application l'a filtré.
• Le focus ou le routage d'entrée de l'OS a laissé tomber l'événement.

Les preuves au niveau bus répondent aux quatre premières. Si les rapports sont présents et valides sur le bus, remontez vers le pilote et l'application. Si les rapports sont manquants sur le bus, déboguez le firmware, le timing d'endpoint ou l'état d'alimentation.

Touches répétées et boutons bloqués

Des touches répétées peuvent survenir quand le rapport « touche enfoncée » est envoyé mais que le rapport « touche relâchée » est manquant ou mal formé. Un bouton de manette peut apparaître bloqué pour la même raison.

Capturez autour de l'événement :

Rapport : touche A enfoncée
Rapport : aucune touche enfoncée

Si le rapport de relâchement n'apparaît jamais, le périphérique ou le chemin USB est suspect. S'il apparaît sur le bus mais que l'application croit toujours que la touche est enfoncée, inspectez le mapping pilote/application.

Pertes de scanner de codes-barres

Beaucoup de scanners émulent des claviers. Un scan peut produire une séquence rapide de rapports HID. Si les rapports sont trop rapides pour l'application, le problème n'est peut-être pas USB. Mais si la trace montre des rapports de touche manquants, des report IDs erronés ou des erreurs d'endpoint, le scanner ou le chemin via le hub peut être responsable.

Preuves utiles :

• Séquence complète de rapports de scan.
• Intervalle des rapports.
• Rapports de relâchement manquants.
• Erreurs d'endpoint.
• Reconnexion ou suspension du périphérique pendant le scan.

Checklist de débogage

Suivez ce flux :

1. Capturez l'énumération depuis le branchement.
2. Enregistrez le HID report descriptor.
3. Identifiez l'endpoint interrupt IN et l'intervalle de polling.
4. Capturez une séquence d'entrée connue.
5. Comparez la longueur réelle du rapport avec le descripteur.
6. Vérifiez les report IDs.
7. Cherchez les paires enfoncé/relâché manquantes.
8. Vérifiez si des erreurs d'endpoint surviennent.
9. Comparez port direct vs hub.
10. Comparez les preuves de bus avec les logs applicatifs.

Diagnostic final

La latence d'entrée USB HID et les rapports manqués ont besoin de preuves du descripteur HID, de l'endpoint interrupt, de l'intervalle de polling et des octets de rapport réels. Un symptôme d'UI ne prouve pas si le responsable est le périphérique, le bus, le pilote ou l'application.

Bus Scope aide à rendre la séquence de rapport HID visible pour que les problèmes de clavier, manette, scanner et HID personnalisé soient débogués à partir de faits USB.