USB-HID-Input-Lag und verpasste Reports: Tastaturen, Gamepads, Scanner und Custom-HID-Geräte debuggen

USB-HID-Probleme werden oft in User-Sprache beschrieben: "Tastatur-Lag, verpasste Tasten, doppelte Eingaben, Barcode-Scanner-Drops, Gamepad-Delay, Fußschalter reagiert nicht oder Custom-HID-Gerät sendet Reports, aber die App erhält sie nie. Suchbegriffe wie "USB HID input lag", "missed HID reports", "HID interrupt endpoint delay", "keyboard repeated keys USB" und "gamepad latency USB capture" zeigen alle auf denselben Engineering-Bedarf: den HID-Report-Flow inspizieren, nicht nur das App-Event." HID-Geräte nutzen üblicherweise Interrupt-Endpoints. Das bedeutet keinen Hardware-Interrupt im Desktop-Sinn; es heißt, dass der Host den Endpoint in einem definierten Intervall pollt. Sind Reports fehlerhaft, verzögert, zu häufig, zu groß oder nicht korrekt beschrieben, sieht die App Lag oder fehlende Eingaben.

Bus Scope hilft, weil HID-Diagnose Deskriptor-, Endpoint-, Polling- und Report-Evidence zusammen braucht.

HID-Report-Deskriptor zählt

Der HID-Report-Deskriptor definiert, was Reports bedeuten. Er beschreibt Usages, Report-Größen, Report-Counts, logische Bereiche, Report-IDs und Input/Output/Feature-Reports.

Passt der Deskriptor nicht zu den tatsächlich gesendeten Bytes, können Symptome seltsam sein:

• App sieht keinen Input.
• Manche Buttons laufen, andere nicht.
• Achsen springen oder sättigen.
• Tastatur-Tasten wiederholen sich.
• Report-ID wird erwartet, aber nicht gesendet.
• Report-Länge weicht vom Deskriptor ab.
• Host verwirft oder ignoriert Reports.

Das Gerät sendet möglicherweise Bytes, aber der Host interpretiert sie falsch.

Interrupt-Endpoint-Polling-Intervall

HID-Interrupt-IN-Endpoints enthalten ein Polling-Intervall. Ein Low-Speed- oder Full-Speed-Gerät kann anders gepollt werden als ein High-Speed-Gerät. Ist das Polling-Intervall zu langsam für den gedachten Use-Case, ist Input-Lag in der Geräte-Konfiguration eingebaut.

Für ein Gamepad oder Real-Time-Control-Gerät zählt das Report-Intervall. Für einen Barcode-Scanner mögen gelegentliche Reports reichen, aber das Report-Framing muss zuverlässig sein.

Endpoint-Deskriptoren prüfen:

• Endpoint-Adresse
• Interrupt-Transfer-Typ
• Max-Packet-Size
• Polling-Intervall
• Device-Speed

Latency nicht allein aus dem App-UI schätzen.

Verpasste Reports vs. verpasste App-Events

Ein Report kann auf mehreren Schichten fehlen:

• Device-Firmware hat ihn nie gesendet.
• USB-Transfer ist fehlgeschlagen.
• Host hat zu langsam gepollt.
• Report wurde gesendet, aber war fehlerhaft.
• Treiber hat ihn anders interpretiert.
• App hat ihn gefiltert.
• Fokus- oder OS-Input-Routing hat das Event verworfen.

Bus-Level-Evidence beantwortet die ersten vier. Sind Reports auf dem Bus vorhanden und valide, gehen Sie nach oben zu Treiber- und App-Handling. Fehlen Reports auf dem Bus, debuggen Sie Firmware, Endpoint-Timing oder Power-State.

Wiederholte Tasten und hängende Buttons

Wiederholte Tasten passieren, wenn der "Key Down"-Report gesendet wird, der "Key Up"-Report aber fehlt oder fehlerhaft ist. Ein Gamepad-Button kann aus demselben Grund hängen.

Capture rund um das Event:

Report: key A down
Report: no keys down

Erscheint der Release-Report nie, sind das Gerät oder der USB-Pfad verdächtig. Erscheint er auf dem Bus, aber die App glaubt weiterhin, die Taste ist gedrückt, prüfen Sie das Treiber/App-Mapping.

Barcode-Scanner-Drops

Viele Barcode-Scanner emulieren Tastaturen. Ein Scan kann eine schnelle Sequenz von HID-Reports erzeugen. Sind die Reports zu schnell für die App, ist USB möglicherweise nicht das Problem. Zeigt der Trace aber fehlende Key-Reports, falsche Report-IDs oder Endpoint-Fehler, sind Scanner oder Hub-Pfad verantwortlich.

Nützliche Evidence:

• vollständige Scan-Report-Sequenz.
• Report-Intervall.
• fehlende Release-Reports.
• Endpoint-Fehler.
• Device-Reconnect oder Suspend während Scan.

Debug-Checkliste

Nutzen Sie diesen Workflow:

1. Enumeration ab Anstecken capturen.
2. HID-Report-Deskriptor speichern.
3. Interrupt-IN-Endpoint und Polling-Intervall identifizieren.
4. Eine bekannte Input-Sequenz capturen.
5. Tatsächliche Report-Länge mit Deskriptor vergleichen.
6. Report-IDs prüfen.
7. Nach fehlenden Down/Up-Paaren suchen.
8. Prüfen, ob Endpoint-Fehler auftreten.
9. Direkter Port vs. Hub vergleichen.
10. Bus-Evidence mit App-Logs vergleichen.

Enddiagnose

USB-HID-Input-Lag und verpasste Reports brauchen Evidence aus HID-Deskriptor, Interrupt-Endpoint, Polling-Intervall und tatsächlichen Report-Bytes. Ein UI-Symptom belegt nicht, ob Device, Bus, Treiber oder App verantwortlich ist.

Bus Scope macht die HID-Report-Sequenz sichtbar, sodass Tastatur-, Gamepad-, Scanner- und Custom-HID-Issues aus USB-Fakten debuggt werden können.