qmk/qmk_firmware

[Bug] DZ65RGB v2 Unresponsive after boot // solution included

Open

#13.026 geöffnet am 28. Mai 2021

Auf GitHub ansehen
 (2 Kommentare) (1 Reaktion) (0 zugewiesene Personen)C (43.867 Forks)batch import
bughelp wanted

Repository-Metriken

Stars
 (20.368 Stars)
PR-Merge-Metriken
 (Durchschn. Merge 20T 9h) (27 gemergte PRs in 30 T)

Beschreibung

I have a DZ65RGB v2 and sometimes it's randomly stuck after booting/power down. The only way to get it back to working is to unplug and replug it which occasionally ends up with the keyboard resetting and loosing the layout.

Describe the Bug

see above. The problem is described by many on reddit: https://www.reddit.com/r/MechanicalKeyboards/comments/ncy8d5/question_about_dz68rgb_v2_unresponsive_after/

System Information

  • Keyboard: DZ65RGB
    • Revision (if applicable): v2
  • Operating system: Linux
  • AVR GCC version: 11.1.0
  • ARM GCC version: 11.1.0
  • QMK Firmware version: 0.12.49
  • Any keyboard related software installed?
    • AutoHotKey
    • Karabiner
    • Other: none.

Additional Context

I added more context on reddit as well as a patch. It is confirmed by many users that the patch indeed works and that the problem is fixed, yet I consider it a bit hacky and don't know if it's worth a pull request. Anyway, here is what I did:

diff --git a/tmk_core/protocol/lufa/lufa.c b/tmk_core/protocol/lufa/lufa.c
index 85d71d083..8ccc8496a 100644
--- a/tmk_core/protocol/lufa/lufa.c
+++ b/tmk_core/protocol/lufa/lufa.c
@@ -435,6 +435,7 @@ void EVENT_USB_Device_Suspend() {
  */
 void EVENT_USB_Device_WakeUp() {
     print("[W]");
+    // suspend_wakeup_init();
 #if defined(NO_USB_STARTUP_CHECK)
     suspend_wakeup_init();
 #endif
@@ -1062,7 +1063,7 @@ int main(void) {
 #if !defined(NO_USB_STARTUP_CHECK)
         if (USB_DeviceState == DEVICE_STATE_Suspended) {
             print("[s]");
-            while (USB_DeviceState == DEVICE_STATE_Suspended) {
+            if (USB_DeviceState == DEVICE_STATE_Suspended) {
                 suspend_power_down();
                 if (USB_Device_RemoteWakeupEnabled && suspend_wakeup_condition()) {
                     USB_Device_SendRemoteWakeup();
@@ -1076,6 +1077,7 @@ int main(void) {
                     //
                     // Pause for a while to let things settle...
                     wait_ms(USB_SUSPEND_WAKEUP_DELAY);
+                    clear_keyboard();
 #    endif
                 }
             }

Digging into the problem made it clear, that the deadlock happens due to an infinite while look during wake-up. I worked around this by changing the while loop to a one-shot command as the whole loop resides in another outer loop. In addition with some delay after the wake-up commands this works quite well.

So if you consider this fix, let me know and I'll create some proper pull request.

Contributor Guide