[Bug] keys are held down when using the keyboard to wake computer from sleep

[vampjaz]

Describe the Bug

I have several keyboards running recent versions of QMK, and all of them have this issue where whatever key i press while the computer is asleep will be held down until i press the key again or power cycle the board. This leads to my password field being spammed with characters for example, or messing with other applications.

System Information

Keyboard: it happens on my YMDK YMD40 and two other custom atmega32u2 based boards, however it seems to not happen on my Drop Ctrl. all of these have firmwares compiled in the last week from various sources.
Operating system: Windows 10 21H1
qmk doctor output:

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.0.0
Ψ QMK home: C:/Users/Kat/qmk_firmware
Ψ Detected Windows 10 (10.0.19043).
Ψ Git branch: master
Ψ Repo version: 0.16.9
⚠ Git has unstashed/uncommitted changes.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 10.1.0
Ψ Found avr-gcc version 8.4.0
Ψ Found avrdude version 6.4
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ QMK is ready to go, but minor problems were found

Any keyboard related software installed?
none, the only relevant configuration is that i have my mouse configured in device manager to never wake the computer, but that setting is left stock for all my keyboards.

Additional Context

you can see my custom config for one of the custom boards here if any of the configuration settings are relevant for it: https://github.com/vampjaz/qmk_firmware/tree/master/keyboards/katstudios/split58
sorry if this is a repeat issue, i searched around several times but couldn't find anything relevant

[filterpaper]

Try the following to see if it helps

#define USB_SUSPEND_WAKEUP_DELAY 3000

[scchow]

I have also run into this issue with my Sofle build using a Elite-Pi, which is rp2040 based.

If I plug in my keyboard and let it sit there for a while (maybe a couple hours), the next time I press a key on the board, the key will be spammed until I replug the board.
This seems to occur even if the computer itself does not go to sleep or suspended mode, since I was working on the same computer using a different board. This occurs intermittently, making it hard to track down the exact starting conditions of this bug.

I also noticed that when this occurs, the RGB lighting on the board that should turn on keypress remains off.
The OLEDs do turn on, but is frozen to the initial state on the first keypress.

This behavior has been observed on the same machine running Ubuntu 20.04 and Windows 10.

I've tried setting

#define USB_SUSPEND_WAKEUP_DELAY 3000

and just turning off the usb starting check altogether in my rules.mk:

NO_USB_STARTUP_CHECK = yes 

but the same issue still occurs.

If it helps, my current settings can be found here:
https://github.com/scchow/qmk_firmware/tree/scchow-sofle/keyboards/sofle/keymaps/scchow

Anyone have any leads on where I should look to debug this issue?

Some potentially related issues:

• [Bug] Key behave as if it was stuck and repeats the last typed letter #19254 - similar but they are using a wireless keyboard. Their issue seems to occur while typing. I have personally not had the key stuck issue happen while I'm typing, but I have not typed on this board for extended periods of time.
• [Bug] Keychron Q4 repeating keys leading to unresponsive board #19295 - their stuck key occurs immediately when the board was flashed, but was somehow fixed when enabling LTO. LTO is already enabled on my board.
• [Bug] kb2040 keyboard unresponsive after resuming from Windows hibernate #18591 - their keyboard is unresponsive after waking from sleep instead of having a stuck key
• [Bug] Adafruit RP2040 Macropad key stuck after Windows resume from sleep #19600 - their problem seems to match mine, although I observe it occurs after a period of inactivity (2-12 hours), not necessarily when the computer sleeps or hiberates.

Edit: I notice that this seems to occur only if RGBLIGHT is enabled. I do not experience freezing if I disable RGB with RGBLIGHT_ENABLE = no. This indicates that something may be wrong when RGBLight is enabled.

This may be related to #5585 that has some recent comments stating that the issue is still unresolved.

[alex-ong]

Chiming in as someone else with a similar problem. I'm using a keebio quefrency and using build from August 2022. I will update this and see if it still persists. For me, the key held down is FN1 (physically, capslock). This leads to typing moving my cursor and a whole bunch of stuff across the screen. It might also be related to split keyboards, who knows.

During the typing of this message, i paused for 20 seconds, and lo and behold my FN key was magically held down. It also occurs more often when coming out of lock screen or sleep. I think they're all related. 🤷

Edit: Update; just built today with adef366

When i plug the keyboard in, FN1 is held down. If i press it, it "releases" it and its good to go.

[crimsonyote]

I have the same issue on my AKKO 5075S VIA. If I can find the version I'll let everyone know