-
-
Notifications
You must be signed in to change notification settings - Fork 39.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove the #10088 hotfix for Teensy 3.1-like Input:Club keyboards #12870
Conversation
It seems to _cause_ the issue it intended to solve there.
I can't approve this PR in its current form. ChibiOS is supposed to abstract this stuff away, and only in cases where ChibiOS doesn't support pieces of functionality (such as bootloaders etc.) do we delve into processor-specific handling of issues. I'd much rather see a proper fix. |
Fair enough. Since I don't own any keyboard that experiences the original issue, I can't really help with a proper fix. Should I change this PR to just revert the original "fix" altogether? Or add a specific define to skip the USB driver restart? |
Just curious if you've tried |
Yep. It had no effect. |
Thank you for your contribution! |
I think something should be done to fix this issue. Maybe not exactly this patch in its current state, but I'd be happy to revise it to something more acceptable. |
How about making the function weak? That way, could throw a revised version in the boards.c in /platforms/chibios/ or wherever. |
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...
I implemented @drashna's suggestion instead. As a side effect, the fix now only affects Input:Club boards (specifically K-Type, Whitefox and Ergodox Infinity). Since I found there was an existing |
for history see: #28 qmk#12870 SonixQMK/ChibiOS-Contrib#24 Co-authored-by: stdvar <[email protected]>
…K#123) for history see: SonixQMK#28 qmk#12870 SonixQMK/ChibiOS-Contrib#24 Co-authored-by: stdvar <[email protected]>
…mk#12870) * Remove the qmk#10088 hotfix for K20x MCU:s. It seems to _cause_ the issue it intended to solve there. * Cleaner way of removing qmk#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.
…mk#12870) * Remove the qmk#10088 hotfix for K20x MCU:s. It seems to _cause_ the issue it intended to solve there. * Cleaner way of removing qmk#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.
Description
On at least my Ergodox Infinity, the #10088 hotfix causes the issue it intended to solve. That is, waking the keyboard from suspend after the keyboard has caused the host to wake works fine without the #10088 hotfix, but with it, the keyboard gets stuck sleeping.
This PR removes the #10088 hotfix for Ergodox Infinity, K-Type and Whitefox (all using the same MK20DX256 MCU).
Types of Changes
Checklist