So far, we were always using HID_USAGE() to determine the Usage ID of a
certain HID report input item. This does not work as intended if a field
is an array and the allowed usages are specified with a usage range, as
HID_USAGE() will return 0. We need to use the field value as an index in
the usage range list in this case instead.
This makes the volume keys in a Microsoft Bluetooth Mobile Keyboard
5000 be properly recognized. The relevant part of the HID report looks
like this:
0xA1, 0x01, // Collection (Application) 0x85, 0x07, // Report ID (7) 0x05, 0x0C, // Usage Page (Consumer) 0x19, 0x00, // Usage Minimum (Unassigned) 0x2A, 0xFF, 0x03, // Usage Maximum (0x03FF) 0x95, 0x01, // Report Count (1) 0x75, 0x10, // Report Size (16) 0x15, 0x00, // Logical Minimum (0) 0x27, 0xFF, 0x03, 0x00, 0x00, // Logical Maximum (1023) 0x81, 0x00, // Input (Data,Array,Abs,No Wrap,Linear,Preferred // State,No Null Position)
When a key such as "volume down" is pressed, the following data is
transferred through Interrupt In:
0x07 0xEA 0x00
This looks like it's more for debugging than for an end user. Maybe put this under boot verbose? The reason is that it's not an error until it's an error, meaning that if we're going to wait for the device when it's not there yet, then printing errors is confusing. Putting it under boot verbose is a nice way for people to get insight into why a boot may be stalled...