* ChibiOS: USB HID control request as dedicated struct
Instead of accessing the raw USB setup packet and documenting the values
as the corresponding USB HID control request fields we introduce a
struct that allows direct access to the fields. This is safer and self
documenting.
* Rename usb_request.h to usb_types.h
In the future all shared USB data types can live in this file.
* Clean up some keyboard/userspace code
* Rename `KEYBOARD_REPORT_BITS` -> `NKRO_REPORT_BITS`
* Add some missing includes
* Use `PACKED` define for report types
* Fix incorrect function signatures for FlexRAM EEPROM driver
* Respect USB_SUSPEND_WAKEUP_DELAY on wakeup
This delay wasn't honored after removing `restart_usb_driver` from the
suspend and wakeup handling. It is now re-introduced in the appropriate
spot, namely after issuing a remote wakeup to a sleeping host.
* Remove old, unused and commented testing code
Problem:
`mousekey_task` spams empty hid reports with when a mouse key is
pressed, causing resource exhaustion in the USB mouse endpoint.
Cause:
The check whether or not to send a new mouse report would always
evaluate to true if a mouse key is pressed:
1. `mouse_report` has non-zero fields and `tmpmr` is a copy of this
fields.
2. `mouse_report` is set to zero, `tmpmr` has now non-zero fields.
3. `has_mouse_report_changed` compares the two and evaluates to true
4. a mouse report is sent.
Fix:
The check condition of `has_mouse_report_changed` will evaluate any
empty record as unchanged, as mouse report data is relative and doesn't
need to return to zero. An empty report will still be send by
`register_mouse` on release of all mouse buttons.
Running the "HID Tests" suite of the USB 3 Command Verifier (USB3CV)
tool resulted in the following error:
(HID: 3.2.61) The report descriptor returned in response to a
GetDescriptor(Report) must be compliant with the HID specification.
Byte Number: 37h ( 55d)
Data Field: 91 02
Mnemonic: Output
Value: (Variable)
Errors: Error: LOGICAL MAX MUST be bounded by Report Size
The error stems from the fact that logical minimum and maximum are
global items, which means that the next item in a report descriptor
inherits the value from the previously set value. In this case the
status leds item inherited the logical minimum (=0) and maximum (=255)
from the keycodes item. As the status leds set a report size of 1 bit,
wich can only hold a boolean, it becomes clear that this range would
never fit.
The fix is straightforward, we just define a appropriate logical maximum
(=1), the mismatch is solved and our keyboard now passes the compliance
tests. Defining the logical minimum is redundant in this case but is
kept to form a logical block.
