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>
* 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.
* 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>
* Add digitizer HID interface for setting the mouse cursor position at
absolute screen coordinates. Tested on Pro Micro, Proton C and
Blackpill.
* Update docs/feature_digitizer.md
Co-authored-by: Ryan <fauxpark@gmail.com>
* Update tmk_core/protocol/usb_descriptor.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Add missing copyrights
Add V-USB support
* Add support for digitizer dedicated endpoint for lufa and chibios.
Fix formatting issues
Move digitizer_task definition to the feature's base implementation file
* Run cformat on modified files
* Change digitizer report usage to Digitizer instead of Pen to avoid
pointer disappearing on Windows.
* Update tmk_core/protocol/vusb/vusb.c
Co-authored-by: Ryan <fauxpark@gmail.com>
* Run cformat from docker image
* Remove send_digitizer from host_driver_t and instead rely on the
declaration being the interface to the implementation in each
HW-specific usb implementation.
* Fix build : send_digitizer shouldn't be static in vusb and add
weak-linkage implementation for tests without usb implementation
* Change digitizer user interface to match pointing device's
* Update documentation with new API
Co-authored-by: a-chol <nothing@none.com>
Co-authored-by: Ryan <fauxpark@gmail.com>
After a USB Reset event the device must, according to the spec wake up
from any suspend state, so the Configured event that arrives afterwards
should be interpreted as an implicit wakeup.
* Remove the #10088 hotfix for K20x MCU:s.
It seems to _cause_ the issue it intended to solve there.
* Cleaner way of removing #10088 hotfix.
Now only affects Ergodox Infinity, Whitefox and K-type, though.
Switches over Ergodox Infinity to the `IC_TEENSY_3_1` board, since that
was a nice place to implement the `restart_usb_driver` override.
However, I would guess this issue is present for other K20x/Teensy 3.1
boards as well...
* Fix comment regarding `IC_TEENSY_3_1` for all keyboards using it.
