[Bug] DZ60 on M1 Macbook Pro often unresponsive after sleep

[ivancuric]

Since I got the M1 MacBook Pro (16-inch, 2021), I'm having issues waking the computer from sleep.

After a while, but not always, the keyboard will be able to wake the mac only once, but the keyboard input won't work on the password input screen or anywhere else. Before, I could also play with the backlight magic keys while the machine was off, and now it only works occasionally. It's a surefire way to see if I will be able to type or not.

In order for the keyboard to work, I have to unplug and replug it every time.

Possibly related issue: https://github.com/qmk/qmk_firmware/issues/5585#issuecomment-1083542476

System Information

Keyboard: DZ60 Revision (if applicable): V2 (USB-C) Operating system: MacOS 12.4 qmk doctor output:

Ψ QMK Doctor is checking your environment.
Ψ CLI version: 1.0.0
Ψ QMK home: /Users/ivan/qmk_firmware
Ψ Detected macOS 12.4.
Ψ Git branch: master
Ψ Repo version: 0.16.9
Ψ CLI installed in virtualenv.
Ψ All dependencies are installed.
Ψ Found arm-none-eabi-gcc version 8.3.1
Ψ Found avr-gcc version 8.4.0
Ψ Found avrdude version 7.0
Ψ Found dfu-util version 0.11
Ψ Found dfu-programmer version 0.7.2
Ψ Submodules are up to date.
Ψ QMK is ready to go

[niw]

As I read your comment on #5585, the behavior I experienced with my different keyboard, Choco60 Rev.2, connected via Apple Studio Display, has similar issue, not responding until I re-plug keyboard when I disconnect and connect Thunderbolt cable from/to MacBook Pro (M1). As I see kernel log, kernel seems not detecting keyboard at all, only recognizing USB 2.0 Hub in display and other Apple's devices such as Apple Mouse connected on it. At this moment, I didn't digging into deeply and not sure if it's firmware issue or macOS issue. Just want to share about my similar experience that you mentioned here and the other thread.

[cnsr]

Having a similar thing happen with Sesame Ergo (atmega32a) and 13" m1 mbp

[niw]

So I solved my problem with Choco60 Rev.2. Turns out it was related to the USB detection and split keyboard detection. It could be unrelated to DZ60, which is not split keyboard, however, the USB detection part might be related, so I want to put some details here.

First, Choco60 Rev.2 is, as I mentioned, a split keyboard and need to detect which side is connected to USB (master) or not when it is connected. It is actually done by that for waiting 2,000ms to detect USB or it default to the side is not connected to USB (slave.) This is enabled by SPLIT_USB_DETECT. And this duration is not enough for Apple Studio Display behavior, which takes long long time to initialize USB somehow. I bumped SPLIT_USB_TIMEOUT to 5000 and SPLIT_USB_TIMEOUT_POLL to 50 (because loop counter is uint8_t, need to bump both or it will overflow.) Even with this 5,000ms duration to wait it, sometime it fails to detect it, but better than 2,000ms default.

While debugging my problem, I also found that the better solution for this slow USB detection is set WAIT_FOR_USB. It will actually wait USB detection before keyboard startup, but I can't use it because it will never success on the side without USB connection (which is obvious.)

So, I am feeling, yet set WAIT_FOR_USB would be worth to try for your DZ60 case. Hope this information helps your case.

[ivancuric]

I added the WAIT_FOR_USB = yes to the DZ60 config, but it hasn't helped.

I'm still experiencing the same issue, but now I can't even trigger the Mac wake with the keyboard, I have to use the mouse.

Previously I could wake the Mac, but the keyboard didn't work. Now it just full-on doesn't work until I replug it.

[cnsr]

Checked this with a Windows machine and everything works just fine there, however when i plug the keyboard into my m1 mac it doesn't work. Replugging it in doesn't help 99% of the time.

Keyboards with blackpill work just fine though.

Here are my rules.mk:

# MCU name
MCU = atmega32a

# Processor frequency
F_CPU = 16000000

# Bootloader selection
BOOTLOADER = usbasploader

# Build Options
#   change yes to no to disable
#
BOOTMAGIC_ENABLE = yes      # Enable Bootmagic Lite
MOUSEKEY_ENABLE = yes        # Mouse keys
EXTRAKEY_ENABLE = yes       # Audio control and System control
CONSOLE_ENABLE = no         # Console for debug
COMMAND_ENABLE = no         # Commands for debug and configuration
NKRO_ENABLE = yes            # Enable N-Key Rollover
BACKLIGHT_ENABLE = no       # Enable keyboard backlight functionality
RGBLIGHT_ENABLE = no        # Enable keyboard RGB underglow
AUDIO_ENABLE = no           # Audio output

NO_USB_STARTUP_CHECK = yes
SLEEP_LED_ENABLE = no
WAIT_FOR_USB = yes
LAYOUTS = alice alice_split_bs

[ivancuric]

Interesting. Are there any significant differences between the two controllers?

[drashna]

IIRC,

NO_USB_STARTUP_CHECK = yes

and

WAIT_FOR_USB = yes

These are mutually exclusive. You want one or the other, not both.

[cnsr]

You want one or the other, not both.

Yeah, I've tried all combinations of those. Nothing helps - works on windows, doesn't on m1 mac.

[ThreeFx]

To throw in my $0.02: I'm seeing the same issue on an 14" M1 MBP with an FC660C and Hasu's controller (running QMK). The stock Leopold controller worked after waking up, however the QMK-based firmware didn't. Unfortunately I did not test the stock TMK firmware, but this suggests a deeper issue than just the DZ60 firmware to me.

[cnsr]

Interesting. Looks like Hasu's controller uses atmega32u4. I also remember having a similar issue on my Seigaiha with atmega328p - sadly can't test it as I've accidentally plugged it with a wrong cable and burned something. I'll eventually try to flash my Sesame with zmk to see if this issue persists.

[ThreeFx]

Okay, I tested 200ms of USB_SUSPEND_WAKEUP_DELAY (in config.h) on my firmware and it works like a charm. The keyboard comes back with no issues at all.

[cnsr]

isn't 200 the default value of USB_SUSPEND_WAKEUP_DELAY?

[ThreeFx]

isn't 200 the default value of USB_SUSPEND_WAKEUP_DELAY?

Seems to be 0. Maybe we should change it to 200 though?

% grep -ri USB_SUSPEND_WAKEUP_DELAY
[ ... ]
./platforms/suspend.h:#ifndef USB_SUSPEND_WAKEUP_DELAY
./platforms/suspend.h:#    define USB_SUSPEND_WAKEUP_DELAY 0
[ .. more omitted ]

[cnsr]

Hm, right here it's listed as 200

https://github.com/qmk/qmk_firmware/blob/master/docs/config_options.md

[ivancuric]

Okay, I tested 200ms of USB_SUSPEND_WAKEUP_DELAY (in config.h) on my firmware and it works like a charm. The keyboard comes back with no issues at all.

Seems to have fixed it as well!

[cnsr]

I finally got around to trying this fix and it indeed seems to have worked!