Лаг ввода и потерянные репорты USB HID: отладка клавиатур, геймпадов, сканеров и кастомных HID

Проблемы USB HID часто описываются пользовательской лексикой: "лаг клавиатуры, пропущенные нажатия, двойной ввод, потери сканера штрихкодов, задержка геймпада, ножная педаль не отвечает, кастомное HID-устройство шлёт репорты, но приложение их не получает. Поисковые запросы вроде «USB HID input lag», «missed HID reports», «HID interrupt endpoint delay», «keyboard repeated keys USB», «gamepad latency USB capture» указывают на одну инженерную потребность: проверить поток HID-репортов, а не только событие приложения." HID-устройства обычно используют interrupt-конечные точки. Это не аппаратное прерывание в десктопном смысле — это значит, что хост поллит конечную точку с заданным интервалом. Если репорты некорректны, задержаны, слишком часты, слишком велики или описаны неверно, приложение может видеть лаг или пропавший ввод.

Bus Scope помогает, потому что диагностика HID требует вместе дескриптор, конечную точку, поллинг и репорты.

Report descriptor имеет значение

HID report descriptor задаёт значение репортов. Он описывает usages, размеры репортов, их количество, логические диапазоны, report IDs и input/output/feature-репорты.

Если дескриптор не совпадает с реальными байтами, симптомы могут быть странными:

• Приложение не видит ввода.
• Часть кнопок работает, часть — нет.
• Оси прыгают или упираются в максимум.
• Клавиши клавиатуры повторяются.
• Ожидается report ID, но он не отправлен.
• Длина репорта отличается от дескриптора.
• Хост отвергает или игнорирует репорты.

Устройство может слать байты, но хост интерпретирует их некорректно.

Интервал поллинга interrupt-конечной точки

HID interrupt IN-конечные точки имеют интервал поллинга. Low-speed или full-speed-устройство может опрашиваться иначе, чем high-speed. Если интервал поллинга слишком медленный для целевого использования, лаг ввода заложен в конфигурацию устройства.

Для геймпада или устройства реального времени интервал репорта имеет значение. Для сканера штрихкодов редкие репорты — это нормально, но фрейминг репорта должен быть надёжным.

Изучите endpoint descriptors:

• Адрес конечной точки
• Тип transfer: interrupt
• Max packet size
• Интервал поллинга
• Скорость устройства

Не угадывайте задержку только по UI приложения.

Пропущенные репорты vs пропущенные события приложения

Репорт может пропасть на нескольких уровнях:

• Прошивка устройства его не отправила.
• USB-передача провалилась.
• Хост поллил слишком редко.
• Репорт был отправлен, но искажён.
• Драйвер интерпретировал его иначе.
• Приложение отфильтровало.
• Фокус или маршрутизация ввода ОС дропнули событие.

Данные на уровне шины отвечают на первые четыре. Если репорты есть и валидны на шине, идите выше — к драйверу и приложению. Если репортов нет на шине, отлаживайте прошивку, тайминги конечных точек или состояние питания.

Повторные нажатия и залипшие кнопки

Повторные нажатия случаются, когда «key down»-репорт ушёл, а «key up»-репорт пропал или искажён. Кнопка геймпада может казаться залипшей по той же причине.

Захватите вокруг события:

Report: key A down
Report: no keys down

Если release-репорт не появляется, подозрение на устройство или USB-путь. Если он есть на шине, а приложение всё ещё думает, что клавиша нажата, проверьте маппинг в драйвере/приложении.

Потери сканера штрихкодов

Многие сканеры штрихкодов эмулируют клавиатуры. Сканирование может дать быструю последовательность HID-репортов. Если репорты слишком быстрые для приложения, проблема может быть не в USB. Но если трасса показывает пропущенные репорты клавиш, неверные report IDs или ошибки конечной точки, виноваты сканер или путь через концентратор.

Полезные доказательства:

• Полная последовательность репортов сканирования.
• Интервал репортов.
• Пропущенные release-репорты.
• Ошибки конечной точки.
• Переподключение устройства или suspend во время сканирования.

Чек-лист отладки

Используйте такой воркфлоу:

1. Захватите перечисление с момента подключения.
2. Сохраните HID report descriptor.
3. Определите interrupt IN-конечную точку и интервал поллинга.
4. Захватите известную последовательность ввода.
5. Сравните реальную длину репорта с дескриптором.
6. Проверьте report IDs.
7. Ищите пропущенные пары down/up.
8. Проверьте, есть ли ошибки конечной точки.
9. Сравните прямой порт и через концентратор.
10. Сопоставьте данные шины с логами приложения.

Итоговый диагноз

Лаг ввода USB HID и пропущенные репорты требуют доказательств из HID-дескриптора, interrupt-конечной точки, интервала поллинга и реальных байт репорта. Симптом UI не доказывает, виноваты устройство, шина, драйвер или приложение.

Bus Scope помогает сделать последовательность HID-репортов видимой, чтобы проблемы клавиатур, геймпадов, сканеров и кастомных HID отлаживались по фактам USB.