Lag de entrada e relatórios perdidos em USB HID: depuração de teclado, gamepad, scanner e HID custom

Problemas de USB HID costumam ser descritos em linguagem de usuário: "lag no teclado, teclas que somem, entrada duplicada, scanner de código de barras que perde leitura, delay no gamepad, pedal que não responde, ou dispositivo HID custom que envia relatórios, mas a aplicação nunca recebe. Termos como "USB HID input lag", "missed HID reports", "HID interrupt endpoint delay", "keyboard repeated keys USB" e "gamepad latency USB capture" apontam para a mesma necessidade de engenharia: inspecionar o fluxo de relatórios HID, não apenas o evento na aplicação." Dispositivos HID normalmente usam endpoints de interrupção. Isso não significa interrupção de hardware no sentido desktop; significa que o host faz polling do endpoint em um intervalo definido. Se os relatórios estão malformados, atrasados, em frequência errada, grandes demais, ou mal descritos, a aplicação pode ver lag ou entrada faltando.

O Bus Scope ajuda porque o diagnóstico HID precisa de evidência de descritor, endpoint, polling e relatório juntas.

O descritor de relatório HID importa

O descritor de relatório HID define o que cada relatório significa. Ele descreve usages, tamanhos de report, contagens, faixas lógicas, report IDs e relatórios de input, output e feature.

Se o descritor não bate com os bytes reais enviados pelo dispositivo, os sintomas podem ficar estranhos:

• A aplicação não vê entrada nenhuma.
• Alguns botões funcionam, outros não.
• Eixos pulam ou saturam.
• Teclas de teclado repetem.
• O report ID é esperado, mas não é enviado.
• O tamanho do relatório difere do descritor.
• O host rejeita ou ignora os relatórios.

O dispositivo pode estar mandando os bytes, mas o host interpretando errado.

Polling interval do endpoint de interrupção

Endpoints HID interrupt IN incluem um polling interval. Um dispositivo low-speed ou full-speed pode ser polled de forma diferente de um high-speed. Se o polling interval é lento demais para o uso previsto, o lag de entrada já está embutido na configuração do dispositivo.

Para um gamepad ou um controle em tempo real, o report interval importa. Para um scanner de código de barras, relatórios ocasionais podem bastar, mas o framing do relatório precisa ser confiável.

Inspecione os descritores de endpoint:

• Endereço do endpoint
• Tipo de transferência por interrupção
• Max packet size
• Polling interval
• Velocidade do dispositivo

Não deduza latência apenas pela UI da aplicação.

Relatório perdido versus evento perdido na aplicação

Um relatório pode estar faltando em várias camadas:

• O firmware do dispositivo nunca enviou.
• A transferência USB falhou.
• O host fez polling devagar demais.
• O relatório foi enviado, mas malformado.
• O driver interpretou diferente.
• A aplicação filtrou.
• Foco ou roteamento de entrada do SO derrubou o evento.

A evidência no barramento responde as quatro primeiras. Se os relatórios estão presentes e válidos no barramento, suba para driver e aplicação. Se os relatórios estão faltando no barramento, o problema é firmware, timing de endpoint ou estado de energia.

Teclas repetidas e botões travados

Teclas repetidas acontecem quando o relatório de "key down" é enviado, mas o de "key up" está faltando ou malformado. Um botão de gamepad pode parecer travado pelo mesmo motivo.

Capture em torno do evento:

Report: key A down
Report: no keys down

Se o relatório de release nunca aparece, o dispositivo ou o caminho USB é o suspeito. Se ele aparece no barramento, mas a aplicação ainda acha que a tecla está pressionada, inspecione o mapeamento driver ou aplicação.

Perdas em scanner de código de barras

Muitos scanners emulam teclado. Uma leitura pode produzir uma sequência rápida de relatórios HID. Se os relatórios forem rápidos demais para a aplicação, o problema pode não ser USB. Mas se o trace mostra perda de key reports, report IDs errados ou erros de endpoint, o scanner ou o caminho do hub pode ser o responsável.

Evidências úteis:

• Sequência completa do relatório de leitura.
• Report interval.
• Relatórios de release faltando.
• Erros de endpoint.
• Reconexão ou suspend do dispositivo durante a leitura.

Checklist de depuração

Use este fluxo:

1. Capture a enumeração desde a conexão.
2. Salve o descritor de relatório HID.
3. Identifique o endpoint interrupt IN e o polling interval.
4. Capture uma sequência conhecida de entrada.
5. Compare o tamanho real do relatório com o descritor.
6. Confira os report IDs.
7. Procure pares down/up faltando.
8. Verifique se aparecem erros de endpoint.
9. Compare porta direta versus hub.
10. Compare a evidência do barramento com logs da aplicação.

Diagnóstico final

Lag de entrada e relatórios perdidos em USB HID precisam de evidência do descritor HID, do endpoint de interrupção, do polling interval e dos bytes efetivos do relatório. Um sintoma na UI não prova se a culpa é do dispositivo, do barramento, do driver ou da aplicação.

O Bus Scope ajuda a tornar visível a sequência de relatórios HID para que problemas de teclado, gamepad, scanner e HID custom possam ser depurados a partir de fatos do USB.