HS60/v2 keyboard unresponsive after PC wakes from sleep

[stanrc85]

Describe the Bug

When using my HS60/v2 keyboard, when my PC goes to sleep/hibernate and then I tap the keyboard to wake the device, the PC will wake up, but immediately after that the keyboard becomes unresponsive. I'm unable to ctrl-alt-del or use any other keys. I have to unplug the keyboard and plug it back in to work again.

This issue doesn't happen with other keyboards, DZ60, 1up60HSE. The device is plugged in directly to back panel of PC, no hub is used.

If I use mouse to wake up PC, then the keyboard works fine once PC is awake.

System Information

• Keyboard: HS60
  • Revision (if applicable): v2
• Operating system: Ubuntu 18.04.2 on Windows 10
• AVR GCC version: 5.4.0

• ARM GCC version: 6.3.1

• QMK Firmware version: 0.6.328

• Any keyboard related software installed?
  • AutoHotKey
  • Karabiner
  • Other:

Additional Context

[yiancar]

@awkannan can you try this in your ARM pcbs as well to see if it is an STM32 problem? maybe someone with a proton c can try as well?

[ISORETURN]

Having the same issue as OP

[Sada-Mio]

I have this problem too but with a dz60rgb

Key input stops registering after waking. However, waking first with mouse is fine.

My dz60rgb has the default rainbow rgb effect/animation. When waking with key press the animation freezes or get stuck on one color.

[shinmai]

For the record, have this same issue with both my rev 6.1 Planck and rev 3 Preonic.
The board appears in Device Manager as "Unkown USB Device (Device Descriptor Request Failed)" with a device status of:

Windows has stopped this device because it has reported problems. (Code 43)
A request for the USB device descriptor failed.

This happens consistently 100% of the time, no matter how long the computer has slept before being woken. Tested both boards on my desktop, and three laptops. Does not occur when waking up with any other attached USB input device.

From a quick search of issues and the /r/olkb subreddit, this seems to be happening only on STM32 powered boards.

[drashna]

Well, I can't reproduce this with my planck rev6 (mono directional) board. But I'm using 8.2.1-1.5 for the arm gcc compiler.

[yiancar]

I will try the newer compiler, but I am not sure it will make a difference.

@drashna could you verify that ur pc is going to sleep? Maybe is set in the bios not to go to full sleep mode?

[shinmai]

Tried building with 8.2.1 (was using 6.3.1 previously), didn't make a difference on my systems.

As a workaround enabling NO_USB_STARTUP_CHECK, the keyboard can no longer wake up the computer, but hitting keys while the computer is sleeping no longer makes it fail to function after resuming from sleep, which if nothing else, is slightly less annoying.

[yiancar]

Ok good to know, if you have a second pc and a debugger I can tell you which pins you can use to attach it. This will let you have a look at which point the usb stack is failing. I am planning to do this myself but I dont have the time atm

[shinmai]

Unfortunately all my embedded paraphernalia is for 8-bit AVRs, I've been meaning to buy a J-Link for the longest time to play with Cortex stuff, but haven't had the time or the money.
I guess if I can find my old dusty Bus Pirate, it can supposedly bit-bang SWD with OpenOCD, but I have no idea how viable that actually is (or where my Bus Pirate is 😂).

[drashna]

@yiancar Yeah, it's definitely going to sleep. I can tell, because it shuts off the keyboards (all 8 of them with RGB), and turns off the RGB stuff inside the case.

[yiancar]

If u have a debugger u can try and follow the code see what happens then

[shinmai]

Far from a fix, more just trying to pin-point stuff without adequate hardware, I've found the following:
Disabling NO_USB_STARTUP_CHECK but adding wait_ms(5000); just before the call to send_keyboard_report(); in qmk_firmware/tmk_core/protocol/chibios/main.c after resuming from a suspended state, will allow my Planck to wake up the computer and function normally after everything has powered up.
I tried with shorter wait times, but 5 seconds seems to be the point where (at least on my desktop) things start working consistently.

Obviously this isn't a fix to the real issue, just a MacGyver hack, but it does function as a temporary workaround for me and might shed some light into where exactly the issue is cropping up before someone with an actual JTAG/SWD debugger can take a proper look at what's going on.

[yiancar]

Hmm this looks like ur usb hub is not sending something to the keyboard within time needed. Only propper way to find out tho is with the swd:)

[shinmai]

That's what I figured, as well. Weid thing is, it happens with both of the root hubs on my ASUS motherboard as well as my Lenovo laptop and my SufaceBook 2, but doesn't happen with any non-QMK keyboards or other USB HID.
Besides wanting to get this fixed, I'm very intrigued to find out what exactly is going on, too.

[Daffclay]

This happens on the dz60rgb aswell. If I press any key on the keyboard when the pc is off, I know for sure the keyboard won't work. Only if I replug the usb c will it function again.

[Sada-Mio]

@Daffclay Yea, it is annoying to replug the usb-c each wakeup. Workaround I've been doing until this is fixed is to wake the PC using the mouse first.

[Daffclay]

@Sada-Mio It happens when pc is completely off aswell. I might have to put a cover on my keyboard so no one presses any keys until I turn the pc on :)

[shinmai]

My hacky workaround of adding a massive 5 second delay inside the initialisation code allows you to use the keyboard to wake up the computer without needing to hotplug afterwards, but obviously also makes it so you need to wait 5 seconds after plugging the board in to type.

[Ciantic]

Can we rename this? This is wider issue. E.g. #6369 is same problem I suspect.

It used to work with 6 month or 1 year old branch of QMK.

This happens to me with Ergodox Ez too, I just upgraded my QMK Firmware. When I resume the computer from sleep (by pressing a key in keyboard), keyboard won't respond when coming to Windows and I have to unplug and plug it back again.

So the steps are:

1. Put computer to sleep
2. Press any key to wake up
3. Computer wakes up
4. All keys stop working
5. Unplug and plug back again and it works.

What is even worse is that I have another (unrelated) bug that requires me to flash each time I unplug and plug the keyboard. So I have to flash each time the computer comes from sleep :(

Apparently NO_USB_STARTUP_CHECK = yes makes it work, but it has a side effect: I can't wake my computer from sleep with keyboard anymore. I suspect I have to live with this.

[yiancar]

As said before in previous issues, This is a problem on how the keyboard goes to sleep etc. I suspect its somewhere in the way we use ChibiOS but I am not sure.

Sadly I do not have the time to investigate this further.

If people want to I would suggest getting an stlink and debug this properly. Might be a ChibiOS back all together, who knows as we use a very old version anyway.

[yiancar]

Ok Guys i need more help to further debug this.
On my work laptop and only windows machine, everything works alright. Can you please let me know on what is the model of the pc your using? I want to check the relevant bios sleep settings and see if we missed something.

[Sada-Mio]

• Windows 10, Gigabyte Aorus Gaming 7 mobo, Anker 10-port usb hub
• Windows 10, H97M-ITX/ac mobo, direct usb
• Macbook 12" 2016 , direct usb

Issue with DZ60RGB waking.

[yiancar]

does it not work with the mac?

[Sada-Mio]

I can't seem to reproduce the issue on mac like the PC which occurs every wake.

Seems more likely to have issues when used with a USB hub since my macbook only has 1 usb-c port. Once in a awhile key input won't work, but most of the time if something breaks it the LED lights that won't turn off or only half of them turn off.

[yiancar]

Can you try the following for me:

remove line 190: print("[s]"); from tmk_core/common/chibios/main.c

if this doesnt work, revert the change and try:

In tmk_core/common/chibios/suspend.c:

line 52: wait_ms(17); to wait_ms(80);

if this doesnt work, revert the change and try:

in tmk_core/common/chibios/main.c:

after line 202: (usbWakeupHost(&USB_DRIVER);) add wait_ms(5000);

[vectorstorm]

I only just saw the question from @yiancar . I’m testing on a Planck EZ, where I have a 100% repro case of keyboard freezing when pressing a key after shutting down the computer. I’m running based upon QMK commit 7372ce6 (“added ability to change Unicode input method”), which is after the ‘future’ branch merge.

1. Removing the print statement: problem remains
2. Reverting and switching suspend.c wait-ms from 17 to 80: problem remains
3. Reverting and adding wait_ms of 5000 immediately after usbWakeupHost: partial workaround

If I just tap a key, then no freeze occurs (keyboard is then unresponsive for five seconds after pressing a key during USB suspension, as expected). However, if I hold a key for five seconds; past the end of the wait, then the freeze does still occur.

This is 100% reliable for me. I’m not sure what it implies about the source of the issue, though?

[xyzz]

Anybody experiencing (or even not experiencing - making sure the change doesn't break anything) the issue, please give a try to #7784

[livtanong]

@xyzz your PR works perfectly! Brilliant!

[brendon-r]

@xyzz works for me as well. Keyboard is responsive during post and I'm even able to get into bios! Great work!

[damiencourousse]

Anybody experiencing (or even not experiencing - making sure the change doesn't break anything) the issue, please give a try to #7784

👍
Works for me as well. Thank you!

[amitraa]

Works for me on KBD65RGB. Brilliant work!

[yiancar]

seems we have a fix :O

[su8044]

Maybe not the right place, but I'm having the same issue with Arduino pro micro clone

[DevPowers]

I was able to apply this fix to my board by building a .hex or .bin file using https://config.qmk.fm/#/ and flashing my board it. It seems this website will grab the latest code from QMK Master branch and compile the .bin/.hex file using your configuration.

[huy172]

@dillonpowers Thanks for advising this
I thought you had to change the actual coding within QMK and I had no idea how to go about it
I've re-flashed my dz65rgb and this is has resolved the issue for me
Thanks for everyone that has helped and contributed to this!

[su8044]

@dillonpowers will updating the qmk repository fix this? im using msys

[DevPowers]

Yeah just download the latest code from the QMK Firmware github and it should work

…

On Sat, Feb 1, 2020, 3:55 AM su8044 ***@***.***> wrote: @dillonpowers <https://github.com/dillonpowers> will updating the qmk repository fix this? im using msys — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5585?email_source=notifications&email_token=AEDALIZIZKTHQDUTLXYHCPDRAU2JZA5CNFSM4HEJGWM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQYBGI#issuecomment-581009561>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDALIY24Y3RHAB5ZOGU5R3RAU2JZANCNFSM4HEJGWMQ> .

[weeheavy]

Thanks @xyzz and @mechmerlin this fix solved the issue on my DZ60 rev. 2.0 too. ❤️

[Tywele]

I still have this bug with a dz60rgbv2. I compiled with the newest qmk firmware 0.13.29 yesterday and when booting up my PC my keyboard is unresponsive until I replug the USB-C.

[ivancuric]

DZ60 is still locking up on a new M1 MBP 16". Haven't had these issues on the previous Mac, or on my PC.

Not using an USB hub, just a simple USB-C to USB 3.0 adapter. The keyboard is connected to the monitor's hub (LG27GL850) along with a G502 mouse which can wake the mac.

Firmware was built using QMK configurator. The keyboard is unresponsive (even the backlight toggle) until i re-plug the USB-C connector, after which the backlight toggle works and the keyboard can wake the Mac.

[sashasimkin]

I have the same problem on Iris rev 6, MacOS 12.3.1

I keep the underlight off, and each time it returns from sleep the keyboard would be unresponsive until re-plugged in.

This has helped me - didn't see the bug for a couple of days:

BACKLIGHT_ENABLE = no
RGBLIGHT_ENABLE = no

[ivancuric]

Thanks, I'll try compiling it manually and see how it goes. I'll get back to you with the results.

…

On Wed, Apr 27, 2022, 11:19 Alex Simkin ***@***.***> wrote: I have the same problem on Iris rev 6, MacOS 12.3.1 I keep the underlight off, and each time it returns from sleep the keyboard would be unresponsive until re-plugged in. This has helped me - didn't see the bug for a couple of days: BACKLIGHT_ENABLE = no RGBLIGHT_ENABLE = no — Reply to this email directly, view it on GitHub <#5585 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVSGJ5YWYPL2YAHDZRVXOTVHEBCTANCNFSM4HEJGWMQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ivancuric]

@sashasimkin nope, the bug is still there.