Qmk_firmware: Keyboard unresponsive during Mac boot

[exiva]

I've noticed my Planck becomes unresponsive when my Mac is booting, or in the bootloader, thus I have to go back to the built in keyboard to unlock FileVault during the machines boot. The keyboard will start to play the chime when powering on my Mac, then it becomes a little distorted, and the keyboard's speaker just continues to make a clicking sound while the Mac is booting. I've tried turning NKRO off, and Mousekeys on/off to no avail. Other keyboards work fine (tested knockoff Mech, Apple and Microsoft)

[exiva]

I poked around the olkb subreddit, and found someone commenting on another issue with the keyboard while booting their Mac 7 months ago, so I reverted to b4c7556 from 7 months ago (No particular reason I chose this commit.) and the issue was sort of resolved. Still had the clicking and distorted chime, but it worked on the bootloader (filevault) login screen. I guess I'll poke around random commits and see if I can find where it broke.

[exiva]

Found it. It's something in the fc80aa9 commit. I'm not sure what yet, will have to investigate it some more.

[jackhumbert]

Awesome - thanks for digging into this! This is merge though - I believe these commits should be outside of this one. I know that my keyboards exhibited the same thing before that point as well :/

[exiva]

Still looking into it, but if you reset to a8e5f6180585f46684d713976ad05d4d81b11ab1 it works on the filevault unlock/bootloader... (For me anyway) then if you reset to the merge fc80aa9 it stops.

[adiabatic]

With my Ergodox EZ, I've had similar problems off and on, depending on the iteration of my layout that I'm using. Currently, it looks like I'm going to have to get a second keyboard to hold the ALT key on bootup for booting into Windows. Re-flashing sometimes 'fixed' it about a year ago, but now, reflashing either my old .hex file or my new .hex file (with some changes) doesn't seem to fix it anymore.

zweihander-old-and-new.zip

[drashna]

Is this still an issue?

[exiva]

It's been ages since I've used my planck or qmk... I'll compile the latest and try it out.

[adiabatic]

Just compiled the latest to swap space and return. I held down ⌥⌘R at boot and it didn't boot into any sort of recovery mode; it just booted normally.

[drashna]

By chance, do you have NKRO enable?

[digizer0]

I'm using a Filco Majestouch 2 Tenkeyless keyboard with latest QMK firmware and the same thing happens. I can't boot into recovery or select boot drive etc., basically any key I press during boot process will be ignored by macOS thus only a normal boot will happen.

I've tried to disable all fancy function like console, mousekey, NKRO, mediakeys, command, bootmagic etc. leaving only the very basic keyboard function on, and the problem still remains.

Hope someone can help debugging this issue. I have a working development environment setup (e.g. compiling, flashing etc.) so I can help if someone can tell me where to fix.

[yanfali]

@digizer0 I just did a test, I am able to enter by unlock password to decrypt by macbook running a filco with a pegasushoof. I am unable to enter any hot key states, so no recovery mode or safe mode short cuts work from the QMK keyboard. I do have NKRO turned off so I can use it to get into the BIOS on a PC.

Can you test a non qmk keyboard and see what results you get? would be interesting to see if macbooks allow hot keys from anything that's not physically connected to the laptop.

@drashna you have a mac mini, can you test getting into recovery mode from a reboot?
Hold GUI + R while turning on macmini.

Thanks

[digizer0]

@yanfali I have Macmini and MBP so I tested on both. They all recognize external USB non-QMK keyboard during boot process so I can successfully use the shortcuts for recovery, single user mode etc. So the issue is not on macOS side. I think it's either a QMK issue or an even lower level issue like at the ATmega controller level.

[digizer0]

Also I tested QMK, TMK and EasyAVR firmware on my keyboard and all have the same issue.

[yanfali]

https://qmk.fm/changes/2018-12-05-only-try-to-read-the-report-id-from-setreport-when-the-keyboard-is-part-of-the-shared-ep you could try playing with these settings. For bios mode on PC's I had to disable nkro. Mac uses uefi to boot and may have some low level needs none of the firmwares meet.

[digizer0]

@yanfali thanks for the info. I actually tried to turn KEYBOARD_SHARED_EP on and off as well because my CapsLock LED is not working so I kinda know this before. KEYBOARD_SHARED_EP has no effect on this issue, macOS will not recognize the shortcuts as always.

I think this issue has something to do with the keyboard initialization logic. For example on a non-QMK keyboard, I can press down and hold ALT/OPTION key before I restart mac and macOS will recognize the ALT/OPTION key is pressed when it reboots, thus allow me to select boot drive. But on my QMK keyboard, it seems the keyboard only accepts key press AFTER it initializes itself. So I have to press and hold ALT/OPTION after macOS restarts and the keyboard is initialized. There is no way to know exactly when the keyboard initialization is finished so the timing is very difficult to get right (I have not succeeded even a single time).

[levitanong]

I'm running into the same issues as well. I've also tried the instructions here to no avail: https://docs.qmk.fm/#/faq_debug?id=problem-on-bios-uefiresume-sleep-amp-wakepower-cycles

When I restart my mac, I always have to disconnect my kb and then reconnect it before it turns on. It's as if disconnecting it makes it remember that it has to draw power.

[levitanong]

Is there on-board memory in the dz65rgb that I can store logs in for later access? I want to try my hand at debugging this.

[levitanong]

I ran a number of tests to more concretely define the behavior.

Abstract:

I ran an experiment on my dz65rgb running QMK, combining 3 binary factors (partition, originating partition, EFI) into a total of 8 tests. The results suggest that the dz65rgb's unresponsiveness is based on a restart originating from the mac partition. A restart from the windows partition (unless a key is pressed before the machine boots) will result in a functioning dz65rgb.

My Setup:

• I'm running Mac OS Catalina, dual booting with Windows 10.
• dz65rgb keyboard (running QMK of course) alongside my macbook pro, So I have access to both dz65rgb and the laptop keyboard

I tried a combination of a number of factors:

1. Default partition (Bootcamp Windows, or Mac OS)
2. Which OS I'm coming from
3. Whether or not I held down the mac option key during boot

The combination of 3 different binary factors = 8 tests.

Tests:

1. Default Windows, From Windows, Held down laptop option key

2. Boots into EFI, dz65rgb functional.

3. Default Windows, From Windows, Allowed natural restart

4. Boots into windows, dz65rgb functional.

5. Default Windows, From Mac, Held down laptop option key

6. Boots into EFI, dz65rgb NOT functional

7. Default Windows, From Mac, Allowed natural restart

8. Boots into windows, dz65rgb NOT functional

9. Default Mac, From Windows, Held down laptop option key

10. Boots into EFI, dz65rgb functional.

11. Default Mac, From Windows, Allowed natural restart

12. Boots into Mac, dz65rgb functional.

13. Default Mac, From Mac, Held down laptop option key

14. Boots into EFI, dz65rgb NOT functional.

15. Default Mac, From Mac, Allowed natural restart

16. Boots into Mac, dz65rgb NOT functional.

Conclusion:

Based on those 8 tests, the dz65rgb keyboard only works when coming from Windows. Be it EFI or a natural boot, the dz65rgb keyboard will work.

Other findings:

• If I boot into windows in a state where the keyboard doesn't work and I log in via my laptop's keyboard, when I unplug my dz65rgb, there's the sound of a device disconnecting. So windows must somehow recognize it's connected, but it's simply not working.
• Given any of the above combinations, if I hold down the dz65rgb alt during boot, it will be unresponsive. EXCEPT for one time when I had Default Windows, From Mac, I was able to get into the EFI by holding the dz65rgb alt, but I could not reproduce it again.

Edit:
Abstract

[levitanong]

This should already be fixed via https://github.com/qmk/qmk_firmware/pull/7784

[digizer0]

Just flashed the latest qmk firmware but unfortunately the issue remains. Also on my keyboard I have never experienced the loss of response from keyboard after resume from sleep. So it seems to be a different issue than what's fixed in #7784.

My keyboard works fine when resume from sleep, but does not work during boot/reboot, e.g. no key press is recognized until the macOS login screen shows up.

Version reported by qmk:
```- Version -
DESC: QMK firmware for Majestouch2 TKL
VID: 0xFEED(Filco) PID: 0x6050(Majestouch2 TKL - The Pegasus Hoof 2015) VER: 0x0104
BUILD: "0.7.108-33-g6eff52-dirty" (15:00:31 Jan 14 2020)
OPTIONS: LUFA MOUSEKEY EXTRAKEY CONSOLE COMMAND 4096
GCC: 8.3.0 AVR-LIBC: 2.0.0 AVR_ARCH: avr35

[reejosamuel]

Anyone found a solution to this? I did some digging but unsure what is the root cause