仓库指标
- 星标
- (20,368 个星标)
- PR 合并指标
- (平均合并 20天 9小时) (30 天内合并 27 个 PR)
描述
Describe the Bug
I believe there is a long-running bug in AVR suspend during PC sleep. It manifests visibly with GPIOs: RGB goes haywire, the board isn't responsive after the PC sleeps until a power cycle, and on the Bit-C the built-in LED turns on. The common workaround is to define NO_SUSPEND_POWER_DOWN in the config.h, but this also keeps the RGB, backlight, etc enabled when the host is put to sleep.
I've also seen a few cases where internal flash gets corrupted (at least on 32U4) and the board needed to be flashed again to bring it back to life. There have been a few attempts to work around and fix this issue, but despite that it pops back up from time to time. When I was originally digging into this, it seemed possible that it was related to clocks since almost all clocks are disabled during power-down, but I never got to a root cause. @drashna advised me to open this issue to brainstorm/track mitigations. Disabling the AVR deep sleep by undefining WDT_vect (required to enter sleep, see https://github.com/qmk/qmk_firmware/blob/master/platforms/avr/suspend.c#L18) fixes this but is a hack.
A few possible examples: https://github.com/qmk/qmk_firmware/issues/19192 https://github.com/qmk/qmk_firmware/issues/14127 https://github.com/qmk/qmk_firmware/issues/6822 https://github.com/qmk/qmk_firmware/issues/6726 https://github.com/qmk/qmk_firmware/issues/5239
There's a separate class of issue related to sleep on M1 Macs -- this is different from that one. The two don't seem to be related.
Keyboard Used
No response
Link to product page (if applicable)
No response
Operating System
No response
qmk doctor Output
No response
Is AutoHotKey / Karabiner installed
- AutoHotKey (Windows)
- Karabiner (macOS)
Other keyboard-related software installed
No response
Additional Context
No response