2026-06-02

Ritardo input USB HID e report mancanti: debug di tastiere, gamepad, scanner e dispositivi HID custom

Come diagnosticare ritardo input USB HID, report mancanti, tasti ripetuti, latenza gamepad, perdite dello scanner, timing dell’endpoint interrupt, polling e descrittore HID.

I problemi USB HID vengono spesso descritti con il linguaggio dell'utente: "tastiera in ritardo, tasti mancati, doppio input, perdite dello scanner barcode, ritardo del gamepad, pedale che non risponde oppure dispositivo HID custom che invia report ma l'app non li riceve mai. Ricerche come "USB HID input lag", "missed HID reports", "HID interrupt endpoint delay", "keyboard repeated keys USB" e "gamepad latency USB capture" indicano tutte la stessa esigenza tecnica: ispezionare il flusso dei report HID, non solo l'evento applicativo." I dispositivi HID usano di solito endpoint interrupt. Questo non significa interrupt hardware nel senso desktop; significa che l'host effettua polling dell'endpoint a un intervallo definito. Se i report sono malformati, in ritardo, troppo frequenti, troppo grandi o descritti in modo scorretto, l'applicazione può vedere latenza o input mancanti.

Bus Scope aiuta perché una diagnosi HID richiede insieme evidenza su descriptor, endpoint, polling e report.

Il HID report descriptor conta

Il HID report descriptor definisce il significato dei report. Descrive usage, report size, report count, range logici, report ID e report input/output/feature.

Se il descriptor non corrisponde ai byte reali inviati dal dispositivo, i sintomi possono essere strani:

L'applicazione non vede input.
Alcuni pulsanti funzionano e altri no.
Gli assi saltano o saturano.
I tasti della tastiera si ripetono.
Il report ID è atteso ma non viene inviato.
La lunghezza del report differisce dal descriptor.
L'host rifiuta o ignora i report.

Il dispositivo può inviare byte, ma l'host può interpretarli in modo sbagliato.

Intervallo di polling dell'endpoint interrupt

Gli endpoint HID interrupt IN includono un intervallo di polling. Un dispositivo low-speed o full-speed può essere interrogato in modo diverso rispetto a un dispositivo high-speed. Se l'intervallo di polling è troppo lento per l'uso previsto, la latenza input è incorporata nella configurazione del dispositivo.

Per un gamepad o un dispositivo di controllo real-time, l'intervallo dei report conta. Per uno scanner barcode, report occasionali possono bastare, ma il framing dei report deve essere affidabile.

Ispeziona gli endpoint descriptor:

Endpoint address
Interrupt transfer type
Max packet size
Polling interval
Device speed

Non dedurre la latenza solo dalla UI dell'applicazione.

Report mancanti vs eventi applicativi mancanti

Un report può mancare a diversi livelli:

Il firmware del dispositivo non lo ha mai inviato.
Il transfer USB è fallito.
L'host ha effettuato polling troppo lentamente.
Il report è stato inviato ma era malformato.
Il driver lo ha interpretato in modo diverso.
L'applicazione lo ha filtrato.
Focus o routing input dell'OS hanno scartato l'evento.

L'evidenza a livello bus risponde ai primi quattro punti. Se i report sono presenti e validi sul bus, sali verso driver e applicazione. Se i report mancano sul bus, fai debug di firmware, timing endpoint o stato di alimentazione.

Tasti ripetuti e pulsanti bloccati

I tasti ripetuti possono comparire quando il report "key down" viene inviato ma il report "key up" manca o è malformato. Un pulsante del gamepad può sembrare bloccato per lo stesso motivo.

Cattura intorno all'evento:

Report: key A down
Report: no keys down

Se il report di rilascio non appare mai, il dispositivo o il percorso USB è sospetto. Se appare sul bus ma l'applicazione pensa ancora che il tasto sia premuto, ispeziona mapping driver/applicazione.

Perdite negli scanner barcode

Molti scanner barcode emulano tastiere. Una scansione può produrre una sequenza rapida di report HID. Se i report sono troppo veloci per l'applicazione, il problema potrebbe non essere USB. Ma se la traccia mostra key report mancanti, report ID errati o errori endpoint, lo scanner o il percorso tramite hub può essere responsabile.

Evidenza utile:

Sequenza completa dei report della scansione.
Intervallo dei report.
Report di rilascio mancanti.
Errori endpoint.
Riconnessione o suspend del dispositivo durante la scansione.

Checklist di debug

Usa questo workflow:

Cattura l'enumerazione dal plug-in.
Salva il HID report descriptor.
Identifica l'endpoint interrupt IN e l'intervallo di polling.
Cattura una sequenza input nota.
Confronta la lunghezza reale del report con il descriptor.
Controlla i report ID.
Cerca coppie down/up mancanti.
Controlla se si verificano errori endpoint.
Confronta porta diretta vs hub.
Confronta l'evidenza bus con i log applicativi.

Diagnosi finale

Ritardo input USB HID e report mancanti richiedono evidenza dal HID descriptor, dall'endpoint interrupt, dall'intervallo di polling e dai byte reali dei report. Un sintomo nella UI non prova se la responsabilità sia del dispositivo, del bus, del driver o dell'app.

Bus Scope rende visibile la sequenza dei report HID, così problemi di tastiere, gamepad, scanner e dispositivi HID custom possono essere analizzati partendo dai fatti USB.

Risposta diretta: da dove iniziare una diagnosi della latenza USB HID?

Scegli un’azione riproducibile: premere e rilasciare un tasto, spostare un asse fino a una posizione nota oppure leggere un solo codice a barre. Registra il momento dell’azione, il primo report HID corrispondente sul bus e la ricezione nell’applicazione. Se il ritardo precede il report, controlla campionamento e firmware. Se il report è corretto e puntuale ma l’app risponde tardi, passa a driver, coda di input, focus e thread applicativo.

Una conclusione verificabile indica punto di cattura, velocità del dispositivo, indirizzo endpoint, bInterval, dimensione massima del pacchetto, Report ID e lunghezza effettiva. “La tastiera USB è lenta” è un sintomo; questi dati definiscono il confine osservato.

Costruisci una finestra di evidenza intorno a un input

Acquisisci enumerazione e descrittori, quindi conserva una finestra breve da prima dell’input fino alla risposta o al primo errore. Per un tasto servono pressione e rilascio. Per un asse, una serie di valori. Per uno scanner, tutti i caratteri compreso il terminatore.

Livello	Evidenza da conservare	Domanda a cui risponde
Descrittore HID	Usage, dimensioni, count, ID, intervalli	Quale formato si aspetta l’host?
Endpoint	Indirizzo, tipo, dimensione, `bInterval`, velocità	Quale opportunità di polling è dichiarata?
Report USB	Tempo, stato, lunghezza, campi decodificati	Che cosa è arrivato al punto di cattura?
Driver/sistema	Stato del device e orario evento	Che cosa accade sopra USB?
Applicazione	Ricezione, focus, filtri	Come viene gestito l’evento?

L’assenza di un report in una cattura host non dimostra che il device non abbia trasmesso sul filo. Verifica bus o root hub, avvio della cattura, permessi e possibili perdite del capturer. La guida alla cattura per piattaforma aiuta a documentare origine e limiti.

Misura la latenza invece di stimarla

Definisci inizio e fine. Un inizio osservabile può essere il completamento dell’Interrupt-IN che contiene la variazione; la fine può essere il timestamp di ricezione dell’app. Per includere il contatto fisico occorre un riferimento esterno o telemetria firmware: la cattura USB non conosce quell’istante.

Ripeti il test nelle stesse condizioni e conserva minimo, mediana, massimo e valori anomali. La media può nascondere una pausa rara che spiega il problema. Mantieni fissi porta, hub, alimentazione, firmware, frequenza dei report, carico di sistema e versione dell’app.

Domanda	Confronto utile	Interpretazione prudente
`bInterval` limita la risposta?	Valore dichiarato contro polling osservato	Non rappresenta tutta la latenza dell’app
L’hub cambia il risultato?	Porta diretta e hub con variabili fisse	Delimita un percorso, non prova da solo un hub guasto
Il resume aggiunge ritardo?	Esecuzione stabile contro Suspend/Resume	Collega solo eventi di alimentazione osservati
L’app perde input?	Report valido senza evento app	Esamina driver e applicazione

Valida Report ID, lunghezza, pressione e rilascio

Se il descrittore dichiara più Report ID, ogni report deve contenere l’ID atteso e la lunghezza corrispondente. Un byte ID assente o duplicato sposta tutti i campi anche quando i byte sembrano plausibili. Confronta ogni report decodificato con il descrittore senza assumere una lunghezza unica.

Prova un tasto, due tasti insieme, ogni pulsante critico, centro ed estremi dell’asse e ritorno al neutro. Il report di rilascio o neutralità deve apparire. Se il firmware invia solo cambiamenti, ogni transizione importante deve produrre un report e una perdita non deve lasciare l’host bloccato senza recupero.

Separa USB dal sovraccarico applicativo

Report USB completi possono arrivare tardi alla UI per thread bloccato, debounce, lettura limitata, perdita di focus o mapping Usage errato. Confronta un ricevitore semplice o log driver con l’app interessata usando lo stesso input. Se il livello inferiore riceve tutto, non modificare il descrittore casualmente.

Se pressione, rilascio o neutro mancano nella finestra bus, conserva stato di trasferimento, errore endpoint, Suspend/Resume e reset. Usa la guida a endpoint Interrupt e bInterval per interpretare velocità e pianificazione.

Come si accetta la correzione?

Ripeti una sequenza nota con carico normale e alto sulla porta interessata. Conserva cattura fallita e corretta, indicando l’unica variabile cambiata o tutte le differenze. Il successo richiede ID e lunghezze validi, coppie pressione/rilascio complete, latenza entro il requisito e lo stesso numero di eventi nell’app.

Caso	Condizione di accettazione
Tastiera o pedale	Nessuna pressione/rilascio persa e nessuna ripetizione inspiegata
Gamepad	Assi stabili, pulsanti completi, nessuna lunga pausa periodica
Scanner	Tutti i caratteri in ordine con un solo terminatore
HID custom	ID, lunghezza e valori coerenti con il descrittore
Suspend/Resume	L’input ritorna senza riconnessione nascosta

Ripeti dopo il riavvio di device e host ed esegui più cicli. Annota firmware, sistema, driver, porta o hub e strumento. La guida troubleshooting di Bus Scope mantiene entrambe le esecuzioni in una sessione revisionabile.

Domande frequenti sul ritardo HID

Un `bInterval` piccolo garantisce bassa latenza?

No. Contribuisce alla pianificazione dell’endpoint in base alla velocità USB, ma campionamento firmware, code host, driver e app aggiungono tempo. Misura la catena osservabile e dichiara ciò che resta fuori dalla cattura.

Report completi in Bus Scope escludono totalmente il dispositivo?

Dimostrano presenza e validità in quel punto e intervallo. Non provano ogni stato interno o ciclo di alimentazione, ma giustificano il passaggio a driver o app quando l’evidenza USB è completa.

Basta aumentare la frequenza dei report?

No senza evidenza. Frequenza, velocità, endpoint, dimensione e capacità host devono essere compatibili. Inviare di più non corregge un layout errato o un rilascio assente e può aumentare il carico.

Che cosa consegnare al team firmware?

Fornisci passaggi, descrittori, sequenza decodificata, tempi di polling, primo report mancante o errato, stato endpoint e confronto delimitato tra errore e successo. Non inviare una cattura enorme senza marcatori né affermare uno stato interno invisibile sul bus.

Così “USB HID è lento” diventa una catena verificabile: dichiarazione del device, polling host, report ricevuti, interpretazione driver ed evento applicativo. Consulta la pagina Bus Scope per il workflow di evidenza o la pagina di download per una cattura breve e sanificata.

Prova del contratto USB per «Ritardo input USB HID e report mancanti: debug di tastiere, gamepad, scanner e dispositivi HID custom»

La risposta diretta è che STALL, timeout o reset non spiega da solo la causa. Prima dimostra che il provider vede il device corretto; poi leggi il contratto del transfer: tipo, direzione, recipient, wValue, wIndex, lunghezza dichiarata e reale, status e stato precedente e successivo. In «Ritardo input USB HID e report mancanti: debug di tastiere, gamepad, scanner e dispositivi HID custom» collega la conclusione alla prima transazione diversa dal caso buono.

Confine	Confronto	Decisione
Piattaforma	provider, permessi, Root Hub o usbmon/XHC20	I record provengono dalla connessione corretta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	L’host invia la richiesta prevista?
Data	direzione, lunghezza e bytes conservati	Il payload rispetta il contratto?
Status	ACK, STALL, timeout o cancellation	Dove termina la transazione?
Stato	configuration, interface, alternate setting, endpoint halt	Il device era pronto?

Inizia prima di reset ed enumeration e conserva descriptors, SET_CONFIGURATION, SET_INTERFACE e il comando precedente al guasto. Un filtro endpoint stretto può nascondere il control transfer decisivo. Esegui un’azione USB documentata per prova e cambia solo firmware, driver, porta, cavo, comando o timing.

Come scrivere una risposta citabile?

Indica request, campi setup, risposta e contesto precedente; poi una prova con una variabile. Bytes non trattenuti non provano packet loss. La vicinanza fra command e reset dimostra correlazione, non causa senza ripetizione o cambio di stato.

Quando è valido il confronto?

Mantieni VID/PID, firmware, speed, topologia, provider, filtro e trigger. Confronta fasi USB semantiche, non frame numbers tra usbmon e USBPcap. Registra inizio, fine, versione, OS, connessione e checksum. Usa il troubleshooting Bus Scope.

I proprietari Semrush restano distinti: free USB analyzer sulla pagina prodotto, best USB protocol analyzer nella comparazione e USB descriptor viewer nella guida descriptor. Nessun volume o KD viene inventato.