HS60/v2 keyboard unresponsive after PC wakes from sleep

stanrc85 commented 5 years ago

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

xyzz commented 4 years ago

Try the following patch to chibios:

diff --git a/os/hal/src/hal_usb.c b/os/hal/src/hal_usb.c
index 314473f89..b013b08b3 100644
--- a/os/hal/src/hal_usb.c
+++ b/os/hal/src/hal_usb.c
@@ -494,6 +494,9 @@ void usbStartTransmitI(USBDriver *usbp, usbep_t ep,
   osalDbgCheck((usbp != NULL) && (ep <= (usbep_t)USB_MAX_ENDPOINTS));
   osalDbgAssert(!usbGetTransmitStatusI(usbp, ep), "already transmitting");

+  if (!usbp->epc[ep])
+    return;
+
   /* Marking the endpoint as active.*/
   usbp->transmitting |= (uint16_t)((unsigned)1U << (unsigned)ep);

Or, alternatively, a qmk change:

diff --git a/tmk_core/protocol/chibios/usb_main.c b/tmk_core/protocol/chibios/usb_main.c
index 740763de2..d90ae4621 100644
--- a/tmk_core/protocol/chibios/usb_main.c
+++ b/tmk_core/protocol/chibios/usb_main.c
@@ -663,7 +663,8 @@ void send_keyboard(report_keyboard_t *report) {
             data = &report->mods;
             size = 8;
         }
-        usbStartTransmitI(&USB_DRIVER, KEYBOARD_IN_EPNUM, data, size);
+        if (USB_DRIVER.epc[KEYBOARD_IN_EPNUM])
+            usbStartTransmitI(&USB_DRIVER, KEYBOARD_IN_EPNUM, data, size);
         osalSysUnlock();
     }
     keyboard_report_sent = *report;

(though you might have to repeat that all over the place where usbStartTransmitI is used).

it fixes the issue for me on an stm32f103 board.

brendon-r commented 4 years ago

@xyzz @drashna beginner's question: will this have any affect on a atmega32u4 board? From my limited understanding, chibios isn't used for them.

EDIT: while waiting for a response I figured I may as well try the changes in case my understanding was incorrect. @drashna , your fix didn't prevent my DZ60RGB from freezing. Noting that the LEDs didn't come on and freeze like they used to, they just never turned on and when I got to WIndows, the keyboard was unresponsive.

EDIT2: @xyzz your change doesn't prevent my keyboard from freezing when I try getting into BIOS by pressing FN+2 (though I didn't apply the qmk change everywhere) but when booting into Windows, the frozen LEDs turn off and the keyboard becomes responsive at the Windows login screen, though LEDs cannot be turned back on.

I noticed that if I do the following, the keyboard will be responsive when I get to Windows:

1) Toggle off the LEDs in Windows when the keyboard is responsive 2) Shutdown the PC 3) Start up the PC 4) Press FN+2 to get into bios (never been able to get this to work) 5) Keep pressing FN+2 (optional) 6) Keyboard is responsive at Windows login screen

EDIT3: Ran make git-submodule and retested as my submodules were out of date. No change in behaviour.

yanfali commented 4 years ago

Also, we can try this experimental patch to see if it helps folks out, just collecting data right now https://github.com/qmk/qmk_firmware/pull/7780/files but not in a GPDR sort of way

xyzz commented 4 years ago

@beerai it's only for chibios-based boards

yanfali commented 4 years ago

Also, please give 7782 a try as it has a different but potentially much better solution to the problem with less intrusive code changes

yanfali commented 4 years ago

@beerai to get into BIOS, you typically have to unconfigure NKRO as most BIOS don't seem to be able to deal with it.

brendon-r commented 4 years ago

@yanfali unfortunately even with NKRO disabled, this issue locks up the board so BIOS is inaccessible in both configurations. I'll try again once one of these fixes lands in master.

xyzz commented 4 years ago

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

livtanong commented 4 years ago

@xyzz your PR works perfectly! Brilliant!

brendon-r commented 4 years ago

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

damiencourousse commented 4 years ago

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

:+1: Works for me as well. Thank you!

amitraa commented 4 years ago

Works for me on KBD65RGB. Brilliant work!

yiancar commented 4 years ago

seems we have a fix :O

su8044 commented 4 years ago

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

DevPowers commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

DevPowers commented 4 years ago

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

On Sat, Feb 1, 2020, 3:55 AM su8044 notifications@github.com 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 https://github.com/qmk/qmk_firmware/issues/5585?email_source=notifications&email_token=AEDALIZIZKTHQDUTLXYHCPDRAU2JZA5CNFSM4HEJGWM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKQYBGI#issuecomment-581009561, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEDALIY24Y3RHAB5ZOGU5R3RAU2JZANCNFSM4HEJGWMQ .

weeheavy commented 4 years ago

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

Tywele commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 https://github.com/qmk/qmk_firmware/issues/5585#issuecomment-1110769156, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAVSGJ5YWYPL2YAHDZRVXOTVHEBCTANCNFSM4HEJGWMQ . You are receiving this because you commented.Message ID: @.***>

ivancuric commented 2 years ago

@sashasimkin nope, the bug is still there.

qmk / qmk_firmware