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?
  • [x] 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 7372ce6afdb (“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?

[vectorstorm]

A thing that I’ve noticed: the Planck EZ has layer lights which light up when you hit the “raise” or “lower” keys. If I trigger this freeze-during-USB-suspend issue by using one of those keys, then the layer light comes on and stays on during the freeze.

Those leds are only turned on inside the Keyboard’s “layer_state_set_kb” call, which I think implies that somehow we’re getting out of the USB suspension ‘while’ loop and actually handling key presses enough to be attempting to change layers? I would have thought that we would stay in the suspension loop until the host actually starts communicating again (in my case, the host is actually off, but still providing power to the keyboard), but I seem to somehow be escaping from it at the time of the freeze?

[drashna]

it may be worth adding a clear_keyboard to the suspension wakeup loop. That may fix the issue with holding.

[shinmai]

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

This is 1:1 my experience with both my rev 6.1 Planck and rev 3 Preonic on my SurfaceBook 2, Lenovo Yoga 920 and old workhorse desktop PC with an Asus Sabertooth Z77 mobo with default-ish BIOS settings.

[vectorstorm]

@drashna Just for clarity.. with this code:

if (suspend_wakeup_condition()) {
    usbWakeupHost(&USB_DRIVER);
    wait_ms(5000);
}

The keyboard doesn't freeze any more during USB suspension states, as long as I have released the key before the wait_ms call completes. (if I'm still holding down the key after that, then I get the freeze, as before) If I modify the code to this:

if (suspend_wakeup_condition()) {
    usbWakeupHost(&USB_DRIVER);
    wait_ms(5000);
    clear_keyboard();
}

Then the keyboard reliably freezes, regardless of how long I've held the key down during the suspend state.

My immediate guess is that whatever misbehaviour the held key is causing, something similar is also being triggered by the clear_keyboard call. I'm going to investigate this further; see what I can dig up.

[fOmey]

This issue recently started happening to me also, I'm using a KDB75 REV2 board.

I use RGBLIGHT_SLEEP. I've noticed if the RGB lights turn on while the PC is sleeping (usually overnight).. I know the keyboard is stuck in this "frozen" state.

Exact same "Unknown USB Device (Device Descriptor Request Failed)" error under devices & printers..

Everything was working fine up until what seems like a recent upstream sync, but looking at the commits I can't notice anything that would cause this? Coincidence perhaps? I've reverted the sync, I will report back if the issue persists.

EDIT: Like magic, no lock ups overnight.. must be a coincidence tho. I spent sometime looking through the commits that were included with the sync and most of which are all keyboard layouts. The one and only commit that wasnt: #6707

I can't see how that could possibly cause this to start happening tho.. might be a intermittent problem, at least in my case?

EDIT 2: Also I wanted to add I have my is keyboard connected right into the back of my PC, no hubs are being used.

Any ideas how I can debug further? Being so intermittent, I'm struggling to come up with anything..

[drashna]

@fOmey this is an unrelated issue, as you're using an AVR based board, and this is an ARM based board. It's two very different sets of code.

If you could, open a separate ticket for your issue.

[drashna]

@vectorstorm Well, the clear_keyboard() function actually tries to send info to the host, so if the USB isn't probably initialized, that may be part of the problem.

Also, it may be worth testing to see if clearing the keyboard prior to idling it fixes the issue.

Also for what it is worth, none of the ARM based boards that I have exhibit this behavior (on windows, linux or macOS, and that's using a planck rev6 and a planck ez).

[huy172]

Hi all, I've currently got the same issue on the dz65rgb, where the keyboard won't be recognized upon boot up or when waking up from sleep after pressing some keys until you disconnect and reconnect the cable.

I've been following some threads on reddit as well as the QMK and KBDfans discord channel in regards to this issue and have tried everything suggested.

This is my first time using QMK and quite new to this but happy to help out or try any possible solutions. Otherwise just hoping there'll be a resolution to this soon :)

[impankratov]

@huy172 have you tried above fix by @vectorstorm?

@drashna did you mean to put clear_keyboard() in suspend call like so:

void suspend_power_down_kb(void)
{
    rgb_matrix_set_suspend_state(true);
    suspend_power_down_user();
    clear_keyboard();
}

?

[huy172]

@impankratov I've had a read through this thread but as this is my first time using QMK as well as not having much exposure to coding, I honestly have no idea how to implement that code into the flash?

Is there any guide to completing this and what @vectorstorm suggested?

[drashna]

@impankratov sort of. For now, there is fine, but in the actual core file, eventually

[livtanong]

Chiming in: running dz65rgb with mac, same problem as many have described. I'm almost certain that https://github.com/qmk/qmk_firmware/issues/1149 is a duplicate of this issue. I also suspect https://github.com/qmk/qmk_firmware/issues/237 is related.

edit: strikethrough

[impankratov]

Just a few updates from my testing with dz60rgb:

Adding clear_keyboard(); in suspend_power_down_kb hook like so:

void suspend_power_down_kb(void)
{
    rgb_matrix_set_suspend_state(true);
    suspend_power_down_user();
    clear_keyboard();
}

doesn't change anything, problem remains.

However, adding wait_ms(5000); after usbWakeupHost(&USB_DRIVER); line solves the issue (in same way as described here)

if (suspend_wakeup_condition()) {
    usbWakeupHost(&USB_DRIVER);
    wait_ms(5000); 
}

FYI @drashna

[brendon-r]

I've also noticed this behaviour on my dz60rgb. @impankratov, is this a recent issue or have you always had this problem with your dz60rgb? Regarding the 5000ms wait, is there not a way to query if the USB state is ready so that we only wait as long as we need to?

[impankratov]

@beerai I've got the board like 1 month ago, had this issue right from the start.

[amitraa]

Having the same issue with DZ65RGB PCB on both macOS and Windows.

Steps to reproduce:

1. Wake computer with any key on the keyboard
2. Keyboard becomes unresponsive until unplugging/plugging back in

[mys721tx]

My Ergodox EZ did not have this problem with firmware I made from the manufacturer site in February 2019. It start to have the same issue when I flashed 0.7.49.

[g3rain1]

Not sure if this helps, but my Preonic Rev3 will not only do this when the PC is asleep but also when the PC is off. Though the mother board is probably supplying power to the USB.

[loginfailed1]

I have the KBDFans KBD67 MKII RGB and it behaves similarly.

When PC is off and boots up the keyboard will work, but if any key is pressed at any time while the PC was off, the keyboard will not work unless unplugged and plugged back in.

When PC is asleep, the keyboard can wake the PC, but will not work after the PC wakes.

When PC is asleep and the mouse is used to wake the PC the keyboard will work.

[drashna]

@mys721tx this is probably unrelated, as the Ergodox EZ is an AVR board, and not ARM. However, by chance, do you have RGBLIGHT Sleep enabled?

[mys721tx]

@drashna Sorry I was unaware of this technical detail and this issue is the closest I can google. My current key map (mys721tx/ergodox_ez_firmware@96ab269) has nothing more than redefined keys. RGBLIGHT_SLEEP is probably inherited from config.h.

Since @Ciantic also encountered a similar issue on their Ergodox EZ, do you think we should open an new issue for it?

[damiencourousse]

I also have this problem on a Preonic Rev3.

I don't have this problem on a Planck Rev4. So this likely rules out the hypothesis related to motherboard / BIOS settings.

[brendon-r]

Probably the most frustrating this is that I'm unable to actually get into my bios with my DZ60RGB. I've tried plugging the keyboard into my computer directly and without even pressing a button, the keyboard will become unresponsive. When I plug it into the usb hub in my monitor, it survives a computer restart.

[drashna]

I wonder if this would fix it: https://github.com/qmk/qmk_firmware/commit/e2cdcead5b10d39198979a99ab32788548962cb9

@vectorstorm