chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread #7784
Conversation
xyzz
force-pushed
the
fix-unconfigured-ep-2
branch
from
980c5fd
to
c6b8772
Compare
|
Rather than returning I would prefer to see a go-to to the unlock code so we don't have to think about 3 unlock sites. What do you think? |
|
Sure. |
|
Looks good on onekey f072 here. |
There was a problem hiding this comment.
Tested on a repeatable use case with NK65, board recovered gracefully after patch. Before that hard lock.
- powered USB 2 hub
- connected to macbook through dongle
- unplug dongle, plug dongle back in
- hadron v3 (arm) locked hard
- previously nk65 locked, after patch it survived
|
Patched hadron v3, now it survives the same test. Approved++ |
|
👍, this fixes Ganymede locking up after sleeps of my MacBookPro, connected through a startech usb-c hub. |
|
I've been running both keyboards continuously with sleep enabled on a macbook. Aside from losing initial keypresses, which is to be expected, keyboard is now well behaved and able to resume correctly. Let's get this merged. |
There was a problem hiding this comment.
My motivation to testing this is because I run a dual boot hackintosh and Windows 10 system. After watching the Witcher on Netflix, I was suddenly inspired to replay Witcher 3. However, to my chagrin, the board I was currently using, the NK65 could not allow me to access my boot menu on restart. Thanks to this, I can now play Witcher 3 without swapping boards lol.
This has been tested using the following methodology
- Shutdown computer
- Turn on computer
- Press F12, or Fn + = key when options are available.
Prior to this change, the methodology listed above never allowed me to successfully enter the boot menu.
This has been tested working on the following Arm boards in my collection
- NK65
- Clueboard 66 hotswap gen 1
- KBD67mkiirgb v1
- DZ60rgb-ansi v1
|
Hello, Thank you for the fix. sorry to be a bother but how do I apply this to my DZ60 rgb? I appreciate any help. thanks |
Depends on how you do your firmware. If you use QMK Configurator to create your firmware, it will already be applied there. If you're compiling locally, you should clone the QMK Firmware repository (instructions – back up your keymap file somewhere safe before you do; a copy-paste to a different folder is fine) – then when you have the repo cloned, move your keymap back and compile it. The firmware you get should have this fix included. |
… the thread (qmk#7784) * chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread * change send_keyboard to only have 1 exit point
… the thread (qmk#7784) * chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread * change send_keyboard to only have 1 exit point
… the thread (qmk#7784) * chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread * change send_keyboard to only have 1 exit point
… the thread (qmk#7784) * chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread * change send_keyboard to only have 1 exit point
|
Thanks so much for fixing this. Solved such a huge headache I had where I had to turn unplug and replug my keyboard each time the mac host went to sleep. |
… the thread (qmk#7784) * chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread * change send_keyboard to only have 1 exit point
… the thread (qmk#7784) * chibios/usb_main: re-check USB status in send_keyboard after sleeping the thread * change send_keyboard to only have 1 exit point
Fixes #5585 (attempt 2)
Description
USB status might change from USB_ACTIVE while the thread is sleeping in
osalThreadSuspendS. If the status is not USB_ACTIVE, we don't have any endpoints and attempting to send on them crashes. Discard these sends. Also fix a race condition in the same function.Types of Changes
Issues Fixed or Closed by This PR
Checklist