* 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.
* Update ChibiOS-Contrib for USB suspend fixes
* Remove S3 wakup workaround
ChibiOS OTGv1 driver has a remote wakeup bug that prevents the device to
resume it's operation. 02516cbc24
introduced a hotfix that forcefully restarted the usb driver as a workaround.
This workaround broke multiple boards which do not use this driver /
peripheral. With the update of ChibiOS this hotfix is now obsolete.
* Remove restart_usb_driver overrides
they are no longer necessary as the workaround is not needed anymore
for stm32f4
* Remove unused RP_USB_USE_SOF_INTR defines
The SOF interrupt is enabled dynamically by the RP2040 usb driver
According to the USB 2.0 spec, remote wakeup should be disabled by
default, and should only be enabled if the host explicitly requests
it. The chibios driver code already takes care of storing this
information, and returning it on GET_STATUS requests. However our
application code has been ignoring it so far.
This is a USB compliance issue, but also a bug that causes trouble
in some cases: On RP2040 targets this has been causing problems if
a key is held down while the keyboard is plugged in. The keyboard
would fail to enumerate until all keys are released. With this
change that behavior is fixed.
Note that for LUFA targets this is already done correctly.
In #18631 some IN notification callbacks that were doing nothing were
removed, which should be a valid thing to do (ChibiOS HAL checks the
`in_cb` and `out_cb` pointers for being non-NULL before invoking those
optional callbacks). However, it turned out that some less popular USB
LLDs (KINETIS and MIMXRT1062) have their own checks for those pointers,
and (incorrectly) skip the ChibiOS callback handling when those pointers
are NULL, which breaks the code for the `USB_USE_WAIT` configuration
option (the waiting thread never gets resumed if the corresponding
callback pointer is NULL).
Add those dummy callbacks again (but use a single function for all of
them instead of individual ones for each endpoint); this restores the
KINETIS and MIMXRT1062 boards to the working state while the LLDs are
getting fixed.
* Move Bluetooth-related function calls up to host/keyboard level
* Remove pointless set_output() call
* Move bluetooth (rn42) init to end of keyboard_init()
* Enable SPI/UART for ChibiOS targets
* Some more slight tweaks
* Add ARRAY_SIZE and CEILING utility macros
* Apply a coccinelle patch to use ARRAY_SIZE
* fix up some straggling items
* Fix 'make test:secure'
* Enhance ARRAY_SIZE macro to reject acting on pointers
The previous definition would not produce a diagnostic for
```
int *p;
size_t num_elem = ARRAY_SIZE(p)
```
but the new one will.
* explicitly get definition of ARRAY_SIZE
* Convert to ARRAY_SIZE when const is involved
The following spatch finds additional instances where the array is
const and the division is by the size of the type, not the size of
the first element:
```
@ rule5a using "empty.iso" @
type T;
const T[] E;
@@
- (sizeof(E)/sizeof(T))
+ ARRAY_SIZE(E)
@ rule6a using "empty.iso" @
type T;
const T[] E;
@@
- sizeof(E)/sizeof(T)
+ ARRAY_SIZE(E)
```
* New instances of ARRAY_SIZE added since initial spatch run
* Use `ARRAY_SIZE` in docs (found by grep)
* Manually use ARRAY_SIZE
hs_set is expected to be the same size as uint16_t, though it's made
of two 8-bit integers
* Just like char, sizeof(uint8_t) is guaranteed to be 1
This is at least true on any plausible system where qmk is actually used.
Per my understanding it's universally true, assuming that uint8_t exists:
https://stackoverflow.com/questions/48655310/can-i-assume-that-sizeofuint8-t-1
* Run qmk-format on core C files touched in this branch
Co-authored-by: Stefan Kerkmann <karlk90@pm.me>
