[Bug] Waking computer from suspend-to-ram (ACPI S3 sleep) using KC_WAKE doesn’t work

[stapelberg]

A user reported that with the Teensy 3.6 based kint36 keyboard controller (for the Kinesis Advantage), waking their computer wouldn’t work.

I looked into this a bit, and noticed:

1. When I suspend my laptop, QMK first goes into USB suspend mode, but then is re-initialized for some reason — maybe the computer removes power and restores it? Not sure how to confirm that. The device is connected directly to my ThinkPad X1 Extreme’s USB port.
   • After being re-initialized, the device stays in ChibiOS’s USB state READY (connected, but not enumerated), so any key presses are discarded and the computer can’t be woken up.
2. During my testing, somehow the device stayed active once (haven’t been able to reproduce more than once), and when I hit the KC_WAKE key, it did power the computer back on, but then it hung indefinitely.

I also tested with the Teensy++ 2.0 based kint2pp keyboard controller, and KC_WAKE doesn’t work there either. Haven’t added serial debug statements to that board yet, though, so I’m not sure if it’s the same symptom.

Any ideas why the device would re-initialize after suspend-to-ram?

When USB devices are plugged into a computer while it’s suspended, I assume they are not enumerated, but should they end up in ChibiOS USB state SUSPENDED?

Describe the Bug

System Information

Keyboard: kint36, kint2pp, possibly others
Revision (if applicable): e1f6fa5
Operating system: Fedora Linux
qmk doctor output:

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.0.0
Ψ QMK home: /home/michael/kinx/qmk_wakeup
Ψ Detected Linux.
⚠ Missing or outdated udev rules for 'atmel-dfu' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'kiibohd' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'stm32' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'bootloadhid' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'usbasploader' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'massdrop' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'caterina' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
⚠ Missing or outdated udev rules for 'hid-bootloader' boards. Run 'sudo cp /home/michael/kinx/qmk_wakeup/util/udev/50-qmk.rules /etc/udev/rules.d/'.
Ψ Git branch: master
Ψ Repo version: 0.16.9
⚠ Git has unstashed/uncommitted changes.
⚠ The official repository does not seem to be configured as git remote "upstream".
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 11.2.0
Ψ Found avr-gcc version 11.2.0
⚠ We do not recommend avr-gcc newer than 8. Downgrading to 8.x is recommended.
Ψ 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?

• AutoHotKey (Windows)
• Karabiner (macOS)
• Other:

Additional Context

[stapelberg]

In the meantime, I set up a different lab setup for testing USB remote wakeup (see kinx-project/kint#59 (comment)) and verified that:

• the kint2pp fully works (wakes up the PC, and produces keypresses afterwards)
• the kint36 almost works (wakes up the PC, stuck afterwards)
• the kint41 does not work at all (does not wake up, stuck afterwards)

The latter two issues are fixed by ChibiOS/ChibiOS-Contrib#346 and ChibiOS/ChibiOS-Contrib#345, respectively.

I’ll close this issue since nothing is wrong in QMK, and the HAL fixes need to go into ChibiOS-Contrib, from where they will eventually trickle into QMK.

[chrishoage]

I am also experiencing this on my Boardsource Blok. If you don't mind would you share how you debugged the USB state READY aspects of this? I'm curious if the same issue is happening on my end.

[stapelberg]

I am also experiencing this on my Boardsource Blok. If you don't mind would you share how you debugged the USB state READY aspects of this? I'm curious if the same issue is happening on my end.

Sure! I connected a USB-to-serial adapter to the serial console pins of the Teensy, then added a couple of printf() calls to

qmk_firmware/tmk_core/protocol/chibios/chibios.c

Line 187 in e3a97eb

if (USB_DRIVER.state == USB_SUSPENDED) {

and lib/chibios-contrib/os/hal/ports/MIMXRT1062/LLD/USBHSv1/hal_usb_lld.c

This NXP app note might be interesting to get a general understanding of what is supposed to happen: https://www.nxp.com/docs/en/application-note/AN5385.pdf