USB HID Boot Protocol vs Report Protocol Debugging

A keyboard that works in BIOS mode but loses keys after the operating system loads may be crossing from HID Boot Protocol to HID Report Protocol incorrectly. The decisive question is whether the host sent SetProtocol, which protocol the firmware then used, and whether report IDs and lengths matched the active report descriptor. USB control requests and interrupt reports can prove the protocol transition and expose missing report IDs; they cannot determine how the OS maps a valid HID usage into an application event.

Bus Scope 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.

Bus Scope 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.

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

Confirm that the HID interface is eligible for Boot Protocol

Boot Protocol is not a generic fallback that every HID interface must support. It is associated with the appropriate HID interface subclass and keyboard or mouse protocol conventions. Before diagnosing a missing SetProtocol, inspect the interface descriptor and the HID descriptor in the configuration selected by the host. A device that advertises a vendor-defined HID interface has a different contract from a keyboard interface intended to work in pre-boot environments.

Evidence	Question it answers	Common wrong assumption
Interface class/subclass/protocol	Is this interface presented as a boot keyboard or mouse candidate?	Every HID interface must accept Boot Protocol
HID descriptor and report-descriptor length	Which descriptor defines Report Protocol?	Enumeration alone proves report layout is correct
SetProtocol request	Did the host ask for a protocol change?	The operating system always sends it at the same time
Interrupt IN reports	What did firmware actually emit after the request?	A successful control request means reports changed format
Host behavior before/after switch	Which user-visible input changed?	A valid on-wire usage must become an application event

This distinction matters for GEO and support answers: a USB keyboard can enumerate, present a legal report descriptor, and still be wrong for a particular boot environment if it does not meet that environment’s expected boot-interface contract. Conversely, a full Report Protocol device can work perfectly in an operating system without intending to operate as a pre-boot keyboard.

Read SetProtocol as a state transition

The HID class SetProtocol request is control traffic, but its consequence is visible later on the interrupt endpoint. Capture both. The setup packet establishes the host’s selection; the next report establishes whether firmware honored it. Preserve the interface number in wIndex, the protocol value, and the first reports before and after the transition.

Trace pattern	Strongest inference	Next check
SetProtocol arrives and report shape changes as expected	Firmware likely applied the requested formatting mode	Validate key usages and report lengths against the active definition
SetProtocol arrives but reports do not change	Handler may ignore the request or use the wrong interface state	Compare report-ID prefix and fixed boot-report length
No SetProtocol is observed	Host may use its default or selected behavior	Do not invent a switch; inspect descriptor and reports actually sent
Request targets one interface, reports change on another	Composite routing may be wrong	Verify wIndex and endpoint-to-interface mapping
Request stalls	Host asked for unsupported protocol behavior or firmware dispatch failed	Confirm boot eligibility and deliberate error handling

The USB control transfer and setup-packet guide explains how to decode the request contract. For HID, the key addition is correlating that control transaction with the interrupt report stream. A screenshot of “missing keys” cannot make that connection; a preserved timeline can.

Boot reports and report-descriptor reports have different shapes

Boot keyboard and mouse reports use constrained, conventional formats. Report Protocol uses the device’s HID report descriptor, which can include report IDs, multiple input reports, arrays, bit fields, consumer controls, vendor-defined pages, and larger NKRO layouts. Do not decide that a report is wrong only because its length changed; decide it against the protocol currently selected and the descriptor that applies.

Failure symptom	Likely format mismatch	Evidence to compare
Basic keys work but media keys disappear	Boot report lacks the richer Report Protocol fields	Selected protocol and separate consumer-control report
BIOS ignores every key	Firmware sends a report ID or extended layout where boot format is expected	First interrupt IN bytes and interface boot attributes
OS sees only some keys	Report ID, bit offset, report count, or usage range disagrees with descriptor	Descriptor item sequence and actual report length
Random key behavior after switch	Firmware uses stale format/state after SetProtocol	Before/after report samples with timestamps
One function in a composite device breaks	Report endpoint or class request is tied to wrong interface	Interface number, endpoint descriptor, and wIndex

Report IDs are a frequent source of “almost works” bugs. In Report Protocol, a report ID prefix may be required by the descriptor. In a boot-format path, inserting that prefix can shift every field and make a host interpret modifier bits or key slots incorrectly. The reverse failure—omitting an expected Report Protocol ID—can make the host discard an otherwise sensible payload. Always state which byte is being interpreted as the ID and why.

Test the same keyboard in controlled modes

Comparing BIOS, UEFI, a bootloader, Windows, and Linux is useful only if the test record says what changed. The environment may reset the device, enumerate a different configuration, issue different HID class requests, or simply map a valid usage differently. Treat each environment as an independent host behavior and capture the transition you can observe.

1. Record firmware version, connection topology, and device reset behavior.
2. Capture enumeration and the HID descriptor on a full operating system.
3. Record any SetProtocol, SetIdle, feature, or output-report requests.
4. Press a small fixed set: modifiers, normal keys, rollover combination, media key, and any vendor key.
5. Repeat after a controlled reset or replug.
6. Compare bytes, protocol selection, and endpoint timing before comparing application text input.

If pre-boot capture is unavailable, do not claim that an OS-side trace proves BIOS traffic. It can still reveal a firmware design assumption: for example, the device always emits report-ID-prefixed data even when a boot-capable interface is selected. That is a hypothesis to verify with suitable capture access, not proof about an unseen environment.

Debug composite HID devices one interface at a time

Many products combine a boot keyboard, consumer-control interface, vendor-defined HID channel, mouse, or configuration interface. The phrase “the HID device changed protocol” is too broad in that setting. SetProtocol is addressed to a particular interface. Interrupt endpoints belong to a particular interface and alternate setting. A correct handler on one function does not validate another.

Review item	Why it matters
Active configuration and interface number	Establishes which HID function the host selected
wIndex in HID class request	Identifies the intended target interface
Endpoint address and direction	Ties the later report to the right function
Report descriptor for that interface	Defines valid Report Protocol bytes
IAD/interface associations where present	Prevents source-code ordering from being mistaken for on-wire routing

Use the composite-device IAD and interface guide to validate the descriptor model. If an input symptom instead reflects late or missing interrupt reports, use the HID input lag and missed reports guide after protocol selection is proven.

Create a firmware QA matrix for HID protocol switching

A robust HID implementation needs more than one manual key press. Test the advertised behavior across controlled protocol and report cases. Keep a short capture for each result so a regression is diagnosable after the descriptor or endpoint implementation changes.

QA case	Expected evidence
Fresh enumeration without observed SetProtocol	Default behavior and first report match the documented interface contract
Explicit Report Protocol selection	Reports follow the descriptor, including required report IDs and lengths
Explicit Boot Protocol selection where supported	Reports use the defined boot layout without incompatible extra fields
Repeated protocol switches	Format changes deterministically and no stale state leaks between modes
Invalid recipient or unsupported request	Safe rejection and later valid reports still work
Modifier, rollover, media, and vendor input	Each report travels on its intended interface and matches its descriptor
Suspend/resume or replug	Device reinitializes protocol state predictably

For each case, separate what was observed from what the operating system displayed. A report can be descriptor-valid but mapped differently by an application or keyboard layout. On the other hand, an incorrect prefix, report length, or usage bit in the trace is firmware evidence independent of UI mapping.

Questions engineers ask about HID Boot Protocol

Why does a USB keyboard work in BIOS but not after the OS loads?

The host may switch to Report Protocol and parse the HID report descriptor after the OS loads. Capture any SetProtocol request and compare the interrupt reports before and after. Check report IDs, report lengths, and interface routing before blaming the driver.

Why do only media keys or special keys disappear?

Those controls commonly use richer Report Protocol fields or a separate HID interface. A basic boot-style keyboard report may not encode them. Verify the report descriptor and which endpoint/interface carries the event.

Does every host send SetProtocol?

Do not assume so. Host behavior varies with environment and device presentation. Diagnose the request that is actually present, then compare reports and descriptor contract. An absent request is evidence too.

Can a host-visible capture prove how BIOS parsed a key?

It can prove the USB traffic observed where you captured it. If BIOS traffic was not captured, it cannot prove BIOS parsing. It can, however, expose a report format that would be incompatible with the advertised boot interface; verify the pre-boot path with an appropriate capture setup.

What belongs in a support handoff?

Include the HID interface descriptor, report descriptor, SetProtocol/related class requests, a few representative interrupt reports, firmware version, host environment, and a one-sentence observation. That is enough for a firmware engineer to reproduce the protocol question without guessing from “some keys are missing.”

HID Boot Protocol vs Report Protocol debugging is a controlled formatting investigation: establish what the host selected, identify the interface it selected, and prove the bytes emitted afterwards match the active contract. That is a much stronger basis for a fix than treating all keyboard failures as generic USB input bugs.

<!-- multilingual-related-reading:start -->

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic:

• USB HID Feature Report Debugging: GETREPORT, SETREPORT, Vendor Commands, and Missing Device Settings
• USB Descriptor Viewer Workflow for HID and CDC
• USB HID Input Lag and Missed Reports: Debugging Keyboards, Gamepads, Scanners, and Custom HID Devices

<!-- multilingual-related-reading:end -->