USB HID input lag와 누락된 report: keyboard, gamepad, scanner, custom HID device 디버깅

USB HID 문제는 사용자의 말로 표현되는 경우가 많습니다. keyboard lag, 누락된 key, double input, barcode scanner drop, gamepad delay, foot pedal 미응답, custom HID device는 report를 보내는데 app이 받지 못하는 문제처럼 보입니다. "USB HID input lag", "missed HID reports", "HID interrupt endpoint delay", "keyboard repeated keys USB", "gamepad latency USB capture" 같은 검색어는 모두 같은 engineering 필요를 가리킵니다. application event만 보지 말고 HID report flow를 검사해야 합니다.

HID device는 보통 interrupt endpoint를 사용합니다. 여기서 interrupt는 desktop 의미의 hardware interrupt가 아니라 host가 정의된 interval로 endpoint를 poll한다는 뜻입니다. report가 malformed, delayed, too frequent, too large이거나 descriptor와 맞지 않으면 application에서는 lag나 누락 input처럼 보일 수 있습니다.

Bus Scope는 HID 진단에 필요한 descriptor, endpoint, polling, report 증거를 함께 보여주기 때문에 도움이 됩니다.

HID report descriptor가 중요합니다

HID report descriptor는 report의 의미를 정의합니다. usage, report size, report count, logical range, report ID, input/output/feature report를 설명합니다.

descriptor가 device가 실제로 보내는 bytes와 맞지 않으면 증상이 이상하게 나타날 수 있습니다.

• Application이 input을 보지 못합니다.
• 일부 button은 동작하지만 다른 button은 동작하지 않습니다.
• Axis가 튀거나 포화됩니다.
• Keyboard key가 반복됩니다.
• Report ID가 기대되지만 전송되지 않습니다.
• Report length가 descriptor와 다릅니다.
• Host가 report를 거부하거나 무시합니다.

device가 bytes를 보내고 있어도 host가 이를 잘못 해석할 수 있습니다.

interrupt endpoint polling interval 확인

HID interrupt IN endpoint에는 polling interval이 포함됩니다. low-speed 또는 full-speed device는 high-speed device와 다르게 poll될 수 있습니다. polling interval이 의도한 용도에 비해 너무 느리면 input lag는 device configuration 안에 이미 내장된 것입니다.

gamepad나 real-time control device라면 report interval이 중요합니다. barcode scanner라면 간헐적 report는 괜찮을 수 있지만 report framing은 신뢰할 수 있어야 합니다.

endpoint descriptor를 검사하세요.

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

application UI만 보고 latency를 추측하지 마세요.

누락된 report와 누락된 application event

report는 여러 layer에서 사라질 수 있습니다.

• Device firmware가 애초에 보내지 않았습니다.
• USB transfer가 실패했습니다.
• Host polling이 너무 느렸습니다.
• Report는 전송됐지만 malformed였습니다.
• Driver가 다르게 해석했습니다.
• Application이 filter했습니다.
• Focus 또는 OS input routing이 event를 떨어뜨렸습니다.

bus-level evidence는 앞의 네 가지에 답합니다. report가 bus 위에 있고 valid하다면 driver와 application handling으로 올라가야 합니다. bus 위에서 report가 없다면 firmware, endpoint timing, power state를 디버깅해야 합니다.

반복 key와 stuck button

"key down" report는 전송됐지만 "key up" report가 누락되거나 malformed이면 key가 반복될 수 있습니다. gamepad button이 stuck처럼 보이는 것도 같은 이유일 수 있습니다.

event 주변을 capture하세요.

Report: key A down
Report: no keys down

release report가 전혀 나타나지 않으면 device 또는 USB path가 의심됩니다. bus에는 나타나는데 application이 여전히 key down이라고 생각한다면 driver/application mapping을 검사하세요.

barcode scanner drop 확인

많은 barcode scanner는 keyboard를 emulate합니다. 한 번의 scan이 빠른 HID report sequence를 만들 수 있습니다. report가 application이 처리하기에 너무 빠른 것이 문제라면 USB가 원인이 아닐 수 있습니다. 하지만 trace가 누락된 key report, 잘못된 report ID, endpoint error를 보여준다면 scanner 또는 hub path가 원인일 수 있습니다.

유용한 증거:

• 전체 scan report sequence.
• Report interval.
• 누락된 release report.
• Endpoint error.
• scan 중 device reconnect 또는 suspend.

디버그 체크리스트

다음 workflow를 사용하세요.

1. plug-in부터 enumeration을 capture합니다.
2. HID report descriptor를 저장합니다.
3. interrupt IN endpoint와 polling interval을 식별합니다.
4. 알고 있는 input sequence를 capture합니다.
5. 실제 report length와 descriptor를 비교합니다.
6. report ID를 확인합니다.
7. 누락된 down/up pair를 찾습니다.
8. endpoint error가 발생하는지 확인합니다.
9. direct port와 hub를 비교합니다.
10. bus evidence를 application log와 비교합니다.

최종 진단

USB HID input lag와 누락된 report는 HID descriptor, interrupt endpoint, polling interval, 실제 report bytes의 증거가 필요합니다. UI 증상만으로는 device, bus, driver, app 중 어디가 책임인지 증명할 수 없습니다.

Bus Scope는 HID report sequence를 보이게 만들어 keyboard, gamepad, scanner, custom HID issue를 USB 사실에 기반해 디버깅할 수 있게 합니다.

바로 답하기: USB HID 입력 지연은 어디서부터 확인해야 합니까?

먼저 반복 가능한 입력 하나를 정합니다. 한 key를 누르고 떼기, axis를 중앙에서 정해진 위치까지 이동하기, 알려진 barcode 하나를 읽기처럼 범위가 명확해야 합니다. 사용자가 동작한 시점, bus에서 처음 관찰된 대응 HID report, driver 또는 OS event, application 수신 시점을 따로 기록합니다. report가 나타나기 전부터 늦다면 device sampling과 firmware queue를 확인합니다. report는 제때 정확하게 도착했는데 app만 늦다면 driver, input queue, window focus, application thread가 다음 조사 경계입니다.

검토 가능한 결론에는 capture point, device speed, endpoint address, bInterval, maximum packet size, Report ID, 실제 report length가 있어야 합니다. “USB keyboard가 느리다”는 증상일 뿐이며, 이 값들이 관찰한 범위를 정의합니다.

입력 하나를 중심으로 증거 창 만들기

enumeration, configuration descriptor, HID report descriptor, endpoint descriptor를 먼저 보존한 다음 입력 직전부터 app 반응 또는 첫 실패까지 짧은 구간을 남깁니다. keyboard는 down과 up을 함께, axis는 연속된 값을, scanner는 terminator를 포함한 전체 문자열을 보존해야 합니다.

증거 계층	보존할 항목	답할 수 있는 질문
HID descriptor	Usage, Size, Count, ID, logical range	host는 어떤 report layout을 기대합니까?
Interrupt endpoint	address, direction, size, bInterval, speed	어떤 polling 기회가 선언됐습니까?
USB report	time, status, length, decoded field	capture point에 실제로 무엇이 도착했습니까?
driver/OS	device state와 event time	USB 위 계층에서 무엇이 일어났습니까?
application	receive time, focus, filter	app이 event를 어떻게 처리했습니까?

host capture에 report가 없다는 사실만으로 device가 wire에 아무것도 보내지 않았다고 단정할 수 없습니다. 올바른 bus 또는 root hub를 골랐는지, 입력 전에 capture가 시작됐는지, permission이 있는지, capture 도구 자체가 놓치지 않았는지 확인합니다. platform capture guide에서 관찰 지점과 한계를 기록할 수 있습니다.

UI 느낌이 아니라 latency를 측정하기

측정 시작점과 끝점을 정의합니다. 관찰 가능한 시작점은 상태 변경이 들어 있는 Interrupt-IN transfer 완료 시각이 될 수 있고, 끝점은 app log의 수신 시각이 될 수 있습니다. 손가락이 물리적으로 닿은 순간까지 포함하려면 외부 time reference 또는 firmware telemetry가 필요합니다. USB host capture 하나만으로는 그 순간을 알 수 없습니다.

동일한 조건에서 여러 번 반복하고 minimum, median, maximum, outlier를 남깁니다. 평균만 보면 사용자 불만을 설명하는 드문 긴 멈춤이 숨겨질 수 있습니다. A/B 비교에서는 port, hub, power state, firmware, report rate, system load, application version을 고정합니다.

측정 질문	유효한 비교	조심스러운 해석
bInterval이 응답을 제한합니까?	선언값과 실제 polling time	전체 application latency는 아닙니다
hub에서 결과가 바뀝니까?	다른 조건이 같은 direct port와 hub	경로를 좁히지만 hub 고장을 단독 증명하지 않습니다
resume 뒤에만 늦습니까?	안정 상태와 Suspend/Resume timeline	관찰된 power event에만 연결합니다
app이 입력을 놓칩니까?	정상 bus report와 누락된 app event	driver와 app을 다음으로 조사합니다

Report ID, length, down과 up 검증하기

descriptor가 여러 Report ID를 선언하면 각 report는 기대한 ID와 그 ID에 맞는 length를 가져야 합니다. ID byte가 빠지거나 중복되면 raw hex가 그럴듯해도 모든 field 위치가 어긋납니다. 모든 report가 같은 길이라고 가정하지 말고 decoded report를 descriptor와 비교합니다.

한 key, 두 key 동시 입력, 중요한 각 button, axis center, 양쪽 extreme, neutral 복귀를 각각 시험합니다. release 또는 neutral report가 명확히 보여야 합니다. firmware가 변경 시에만 report를 보낸다면 중요한 상태 전환마다 report가 생성되고 하나를 잃어도 host가 영구적인 pressed state에 남지 않는 recovery가 있어야 합니다.

USB 문제와 application backlog 분리하기

USB report가 완전해도 blocked UI thread, debounce filter, 제한된 read rate, focus loss, 잘못된 Usage mapping 때문에 화면 반응이 늦을 수 있습니다. 동일한 입력 sequence를 simple receiver 또는 driver log와 문제가 있는 app에서 비교합니다. 아래 계층이 모든 event를 받았다면 상위 문제를 가리기 위해 HID descriptor를 임의로 바꾸면 안 됩니다.

반대로 올바른 bus 구간에서 down, up, neutral report가 빠진다면 transfer status, endpoint error, Suspend/Resume, Reset을 보존합니다. Interrupt endpoint와 bInterval guide를 사용해 device speed와 실제 polling schedule을 확인합니다.

수정 뒤 acceptance test는 무엇입니까?

문제가 있었던 port에서 정상 부하와 높은 부하로 알려진 sequence를 반복합니다. 실패 capture와 수정 capture를 한 case에 두고 변경한 변수를 명시합니다. 통과하려면 Report ID와 length가 맞고, down/up pair가 모두 존재하며, latency가 product 기준 안에 있고, application event count가 일치하고, stuck state가 없어야 합니다.

대상	통과 조건
keyboard 또는 foot pedal	누락된 down/up과 설명되지 않는 repeat가 없음
gamepad	axis가 안정되고 button이 완전하며 긴 주기 멈춤이 없음
barcode scanner	모든 문자가 순서대로 있고 terminator가 한 번만 있음
custom HID	ID, length, value가 descriptor와 일치함
Suspend/Resume	기록되지 않은 재연결 없이 input이 돌아옴

device와 host를 재시작한 뒤 다시 시험하고 여러 cycle을 실행합니다. firmware, OS, driver, port 또는 hub, capture tool을 기록합니다. Bus Scope troubleshooting guide는 실패와 성공 run을 검토 가능한 session으로 보존하는 데 도움이 됩니다.

HID 입력 지연과 누락 report FAQ

작은 bInterval은 낮은 지연을 보장합니까?

아닙니다. USB speed에 따른 endpoint schedule의 일부이며 firmware sampling, host queue, driver, app 시간이 추가됩니다. 관찰 가능한 chain을 측정하고 capture 밖의 경계를 명시해야 합니다.

Bus Scope에서 report가 모두 보이면 device는 완전히 무관합니까?

해당 capture point와 test window에서 report가 존재하고 형식이 맞는다는 것은 증명합니다. 모든 firmware 내부 상태와 power cycle까지 증명하지는 않습니다. 하지만 USB evidence가 완전하다면 driver 또는 app으로 조사를 이동할 근거가 됩니다.

report rate를 높이면 해결됩니까?

증거 없이 높이면 안 됩니다. rate, speed, endpoint configuration, report size, host capacity가 맞아야 합니다. 더 자주 보내도 잘못된 layout이나 빠진 release report는 고쳐지지 않고 부하만 늘 수 있습니다.

firmware 팀에는 무엇을 전달합니까?

재현 절차, descriptor, decoded report sequence, polling time, 첫 누락 또는 malformed report, endpoint status, 실패와 성공의 제한된 비교를 전달합니다. 표시가 없는 거대한 capture만 보내거나 bus에서 보이지 않는 내부 원인을 단정하지 않습니다.

이 과정은 “USB HID가 느리다”를 검증 가능한 chain으로 바꿉니다. device가 무엇을 선언했는지, host가 언제 poll했는지, 어떤 report가 도착했는지, driver가 어떻게 해석했는지, app이 무엇을 받았는지 분리할 수 있습니다. Bus Scope product page에서 evidence workflow를 확인하거나 download page에서 짧고 통제된 local capture를 시험할 수 있습니다.

<!-- bus-scope-localized-transaction-foundation-v1:start -->

“USB HID input lag와 누락된 report: keyboard, gamepad, scanner, custom HID device 디버깅”의 USB 계약 시험

직접적인 답은 STALL, timeout, reset 하나만으로 원인을 설명할 수 없다는 것입니다. 먼저 capture provider가 올바른 device를 보는지 증명하고 transfer 계약을 읽습니다. 종류, 방향, recipient, wValue, wIndex, 선언 길이, 실제 길이, status, 전후 상태를 확인하고 known-good과 처음 달라지는 transaction에 결론을 연결합니다.

경계	비교 근거	판단
platform	provider, 권한, Root Hub, usbmon/XHC20	올바른 연결의 record인가
setup	bmRequestType, bRequest, wValue, wIndex, wLength	host가 의도한 요청을 보냈는가
data	방향, 길이, 보존 bytes	payload가 계약과 맞는가
status	ACK, STALL, timeout, cancellation	transaction이 어디서 끝났는가
state	configuration, interface, alternate setting, halt	device가 요청을 받을 상태인가

reset과 enumeration 전부터 capture하여 descriptor, SET_CONFIGURATION, SET_INTERFACE, 실패 직전 command를 남깁니다. 좁은 endpoint filter는 결정적인 control transfer를 숨길 수 있습니다. 시험 한 번에는 문서화한 USB 동작 하나만 수행하고 firmware, driver, port, cable, host command, timing 중 하나만 바꿉니다.

인용 가능한 답

관찰한 request, setup field, 응답, 직전 상태를 쓰고 한 변수만 바꾸는 다음 시험을 제시합니다. retention 때문에 보존되지 않은 bytes는 packet loss 증명이 아닙니다. command와 reset의 시간적 근접은 상관관계이며 상태 전환이나 반복 없이 원인으로 단정할 수 없습니다.

VID/PID, firmware, speed, topology, provider, filter, trigger를 고정하고 usbmon과 USBPcap의 frame number 대신 USB 의미 단계로 비교합니다. 시작·종료, 버전, OS, 연결 위치, checksum을 기록하고 Bus Scope 문제 해결에서 검토합니다.

Semrush owner는 분리합니다. free USB analyzer는 제품 페이지, best USB protocol analyzer는 비교 페이지, USB descriptor viewer는 descriptor 안내가 담당합니다. 이 지원 글에 확인되지 않은 검색량이나 KD를 만들지 않습니다.

<!-- bus-scope-localized-transaction-foundation-v1:end -->