* 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.
* 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
* 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.
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.
* Disable RESET keycode because of naming conflicts
* Add Pico SDK as submodule
* Add RP2040 build support to QMK
* Adjust USB endpoint structs for RP2040
* Add RP2040 bootloader and double-tap reset routine
* Add generic and pro micro RP2040 boards
* Add RP2040 onekey keyboard
* Add WS2812 PIO DMA enabled driver and documentation
Supports regular and open-drain output configuration. RP2040 GPIOs are
sadly not 5V tolerant, so this is a bit use-less or needs extra hardware
or you take the risk to fry your hardware.
* Adjust SIO Driver for RP2040
* Adjust I2C Driver for RP2040
* Adjust SPI Driver for RP2040
* Add PIO serial driver and documentation
* Add general RP2040 documentation
* Apply suggestions from code review
Co-authored-by: Nick Brassel <nick@tzarc.org>
Co-authored-by: Nick Brassel <nick@tzarc.org>
...when attempting to start a receiving USB transfer. Previously, we would
check on the IN endpoint which is the transmitting part of the USB endpoint.
This is wrong and lead to two USB transfers being started immediately
after each other in case of e.g. RAW HID endpoints:
1. When finishing an OUT transfer the low level USB driver calls the out_cb
callback, which in turn initiates another OUT transfer by calling
qmkusbDataReceived.
2. When the raw hid receive channel runs empty inside the raw_hid task,
another OUT transfer is started to potentially fill the channel again. This
happens by calling ibnotify.
Both events occur directly after each other, thus triggering the bug.
* the size variable was redeclared (hiding the variable of the outside scope) and therefore the while check was always false, so the compiler just removed the do while loop, but it would be better to read all data and only exit the task, after this is done
* ChibiOS: add support for HID Programmable Buttons
Fixes#15596
* Enable SHARED_ENDPOINT when PROGRAMMABLE_BUTTON is enabled
The Programmable Button driver expects the shared EP to be enabled.
So enforce this invariant.
* Add support for building against ChibiOS svn/trunk.
* Swap to 21.6.x
* Update to latest branch revision as released version is broken.
* Updated configs.
* Conf updates.
* Updated ChibiOS
* Convert STM32L422 to actual L422 ChibiOS platform.
* Downgrade to 20.3.4 as ChibiOS 21.6.x is being aborted.
* Rollback L422-based boards.
* Remove SERIAL_LINK
* more stale paths in doxygen-todo
* Fix
* More refs
* Update testing docs
* Update doxygen-todo
Co-authored-by: Ryan <fauxpark@gmail.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add power tracking API to lufa and chibios targets
* power.c: Pass through power state to the notify function
* power: added notify_power_state_change_user too.
* making it pass the PR linter
* Add a POWER_STATE_NO_INIT state, that we start in before calling power_init();
* Rename *power* to *usb_power*
* removing stray newline
* Rename usb_power* to usb_device_state*
* Update quantum/usb_device_state.h
Co-authored-by: Drashna Jaelre <drashna@live.com>
* Fix comment
* usb_device_state.h: Don't include quantum.h, only the necessary headers.
Co-authored-by: Drashna Jaelre <drashna@live.com>
