qmk/qmk_firmware

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

Open

#13.026 aperta il 28 mag 2021

Vedi su GitHub
 (2 commenti) (1 reazione) (0 assegnatari)C (43.867 fork)batch import
bughelp wanted

Metriche repository

Star
 (20.368 star)
Metriche merge PR
 (Merge medio 20g 9h) (27 PR mergiate in 30 g)

Descrizione

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.

Guida contributor