Electronic – Why does GET_REPORT on the HID Keyboards sometimes return an empty packet

hidusb

I'm writing boot firmware on a PowerPC board, and I have a problem with spurious USB keyboard repeating. My firmware is based on u-boot: after enumeration it puts the keyboard into boot protocol, then polls it by sending GET_REPORT control packets. From my reading of the HID specification, the keyboard should simply send back the key states and leave my firmware to detect key changes.

This brings back the key states correctly almost all the time, but every keyboard I have tested also sends back occasional empty packets, which the firmware interrupts as a key-up event. In the worst case this happens every 7ms. Here's a trace from the analyzer:

Empty HID report

In the image above transfers 76 and 78 show the correct key code (I'm holding down 'a' throughout), but transfer 77 is all zeroes.

Is there some configuration I'm missing here, or is the only workaround to ignore empty reports unless I see two in a row?

Best Answer

Interesting. As a developer of keyboard firmware my guess would be that these boards internally rebuild the report each key-matrix scan cycle without blocking interrupts while doing so. This would work fine if sending the report is initiated by the keyboard controller (it'll just write the new report into the IN pipe buffer), but could cause empty packets if the report is read asynchronously via GET_REPORT (EP0 handler is invoked by an interrupt.)