qmk/tmk_core, branch master

Revert changes to ChibiOS Suspend Code (#21830)

2023-08-27T02:52:12+00:00

* Partially revert #19780 * Finish * Get teensy 3.5/3.6 board files too * fix lint issue * Revert "[Bug] Restore usb suspend wakeup delay (#21676)" This reverts commit e8e989fd7ad7c10e725e50ae8b0a4426e09f7f30. * Apply suggestions from code review Co-authored-by: Joel Challis --------- Co-authored-by: Joel Challis

[Bug] Restore usb suspend wakeup delay (#21676)

2023-08-02T22:42:57+00:00

* 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

Fix mouse-key spamming empty reports (#21663)

2023-08-02T11:47:25+00:00

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.

Update keyboard report descriptor for USB compliance (#21626)

2023-07-28T00:05:01+00:00

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.

quantum: remove direct `quantum.h` includes (#21507)

2023-07-16T13:42:56+00:00

Eliminate `TMK_COMMON_*` in makefiles (#21517)

2023-07-15T07:27:32+00:00

tmk_core: remove direct `quantum.h` includes (#21465)

2023-07-07T11:24:07+00:00

Get rid of `USB_LED_KANA` and `USB_LED_COMPOSE` (#21366)

2023-06-26T23:15:33+00:00

[Bug] Fix non-functional S3 wakeup / resume from suspense (#19780)

2023-06-26T21:55:52+00:00

* 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

Chibios USB: Take into account if host wants remote wakeup or not (#21287)

2023-06-26T08:36:32+00:00

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.