unconditionally send boot report

[tlyu]

This is a partial proof of concept fix for #1305. It always sends Boot Keyboard reports.

It requires a coordinated change keyboardio/KeyboardioHID#99. It will check for a macro that is only present in a new enough version of KeyboardioHID.

[obra]

when everything is all done, will we have a way to disable the NKO report so that only the boot protocol report goes out? I suspect that there may be environments where that is the actual quirk we need to work around.

[tlyu]

when everything is all done, will we have a way to disable the NKO report so that only the boot protocol report goes out?

I think that's trickier than it sounds. With the current draft PRs, if a host sets the Boot Keyboard to Boot Protocol, the non-boot interfaces won't send any reports. If a non-HID-aware host expects Boot Protocol, but doesn't explicitly set it as required by the HID spec, we will send the other reports. The host probably won't poll those endpoints, so those sends will time out (250ms, currently, which is probably user-visible). I'm very curious whether FreeBSD falls into this category.

We could make an option that is effectively "don't send any non-boot reports unless the host has taken some action that implies that it will understand them". I'm wary of doing that by default, because nothing requires a HID-aware host to do anything other than configure the device and start polling the interrupt endpoints.

In practice, HID-aware hosts tend to do at least one of the following before polling HID interfaces:

• GetDescriptor(Report)
• SetReport(Output) (to set the LEDs)
• SetIdle
• SetProtocol(Report) on the boot interfaces

I think even Windows 10, which doesn't send SetProtocol(Report) or request GetDescriptor(Report) after reset when coming out of hibernation, still sends SetIdle and SetReport(Output) at that time. Almost any host that does its own key repeat management tends to send SetIdle(0) to minimize bus traffic.

[tlyu]

The feedback we have on the OpenBSD behavior suggests that maybe we want to try the approach of prepending the boot report as padding to the NKRO report.

I don't know whether this will cause problems for pre-boot or KVM environments that don't request Boot Protocol, but do expect only 8 bytes.