the tmk_core chibios protocol_pre_task does not
process any usb events when the host is in suspend.
I think there is a race condition where the usb_event_queue_task
will not be processed depending on when usb goes to sleep.
so we may fall into the
while (USB_DRIVER.state == USB_SUSPENDED) {
which comes directly from the hardware interrupt.
and never process pending events in
usb_event_queue_task();
Signed-off-by: Kieran Levin <ktl@frame.work>
Doesn't work yet, on Windows, because Windows will make a special
control request if it sees this.
On Linux lsusb shows it like this:
```
Binary Object Store Descriptor:
bLength 5
bDescriptorType 15
wTotalLength 0x0048
bNumDeviceCaps 2
USB 2.0 Extension Device Capability:
bLength 7
bDescriptorType 16
bDevCapabilityType 2
bmAttributes 0x00000000
(Missing must-be-set LPM bit!)
Platform Device Capability:
bLength 28
bDescriptorType 16
bDevCapabilityType 5
bReserved 0
PlatformCapabilityUUID {d8dd60df-4589-4cc7-9cd2-659d9e648a9f}
CapabilityData[0] 0x00
CapabilityData[1] 0x00
CapabilityData[2] 0x03
CapabilityData[3] 0x06
CapabilityData[4] 0x48
CapabilityData[5] 0x00
CapabilityData[6] 0x01
CapabilityData[7] 0x00
```
Signed-off-by: Daniel Schaefer <dhs@frame.work>
* 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. 02516cbc24647f522eee975e69cc0c8a925470eb
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.
To toggle the system's "Airplane mode" via HID (disable WiFi and Bluetooth).
Add Keycode `KC_AIRPLANE_MODE` with alias `KC_AIRP`.
Needs to be enabled with `EXTRAKEY_ENABLE = yes`.
Signed-off-by: Daniel Schaefer <git@danielschaefer.me>
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.
