USB HID Boot Protocol vs Report Protocol Debugging: Keyboard BIOS Mode, SetProtocol, Report IDs, and Missing Keys

USB HID keyboards and mice can use Boot Protocol or Report Protocol. Users search for "HID Boot Protocol", "HID Report Protocol", "USB keyboard BIOS mode", "SetProtocol HID", "keyboard works in BIOS but not OS", and "HID report ID missing keys" when input works in one environment but fails in another.

BusScope is useful because the host can send HID class requests that change how the device formats reports. If firmware ignores SetProtocol or sends the wrong report format, keys may disappear even though the device enumerates correctly.

Boot Protocol

Boot Protocol is a simplified HID format used by BIOS, UEFI, pre-boot environments, and simple host stacks. It lets basic keyboards and mice work before a full HID parser is available.

Symptoms involving Boot Protocol:

• Keyboard works in BIOS but fails in OS.
• Keyboard works in OS but not boot menu.
• Special keys disappear in pre-boot mode.
• Mouse works only after operating system loads.
• Firmware sends report IDs when boot report expects none.

The diagnostic question is which protocol the host selected.

Report Protocol

Report Protocol uses the HID report descriptor. It supports richer layouts, report IDs, vendor-defined reports, media keys, sensors, and composite behavior.

If the host switches to Report Protocol but the device keeps sending Boot reports, the OS may parse input incorrectly. If the host requests Boot Protocol but the device sends Report Protocol, BIOS may ignore reports.

SetProtocol request

The HID class request SetProtocol can switch between Boot Protocol and Report Protocol for supported devices.

Evidence to collect:

• HID interface descriptor.
• Boot subclass and protocol values.
• Report descriptor.
• SetProtocol request.
• Protocol value selected by host.
• Interrupt IN report bytes before and after switch.

BusScope can make this sequence visible.

Report IDs and missing keys

Report Protocol may use report IDs. Boot Protocol often expects fixed-size reports without report ID prefix.

Common firmware bugs:

• Device includes report ID in Boot Protocol.
• Device omits report ID in Report Protocol.
• Device changes report size but descriptor does not match.
• Media keys are only in a secondary report.
• NKRO report is sent before host enables it.
• Keyboard sends vendor report on keyboard endpoint.

These bugs create search phrases like "USB keyboard missing keys" and "HID report ID wrong."

BIOS vs operating system behavior

BIOS and UEFI environments are usually stricter and simpler than full operating systems. A keyboard can look fine on Windows or Linux but fail before boot.

Useful comparison:

• Capture during pre-boot if possible with external analyzer.
• Capture after OS loads.
• Compare SetProtocol behavior.
• Compare report payload format.
• Check whether device resets between environments.

Even if pre-boot capture is hard, OS-side SetProtocol evidence can reveal firmware assumptions.

Debug checklist

Use this process:

1. Capture enumeration.
2. Inspect HID interface subclass and protocol.
3. Inspect HID report descriptor.
4. Find SetProtocol requests.
5. Decode selected protocol.
6. Compare interrupt IN reports before and after.
7. Check report ID usage.
8. Test normal keys and media keys.
9. Compare BIOS, bootloader, Windows, and Linux behavior.
10. Preserve descriptor and report bytes together.

Final diagnosis

HID Boot Protocol and Report Protocol failures are report-format negotiation problems. The device may enumerate correctly while sending reports in the wrong protocol format.

BusScope helps prove whether missing keys, BIOS input failures, or HID compatibility issues come from SetProtocol handling, report IDs, descriptor mismatch, or firmware report formatting.