Keyboard unresponsive during Mac boot

exiva commented 7 years ago

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

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

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

jackhumbert commented 7 years ago

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

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

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

Is this still an issue?

exiva commented 6 years ago

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

adiabatic commented 6 years ago

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

By chance, do you have NKRO enable?

digizer0 commented 5 years ago

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

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

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

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

yanfali commented 5 years ago

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

@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).

livtanong commented 5 years ago

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.

livtanong commented 4 years ago

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.

livtanong commented 4 years ago

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:

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

The combination of 3 different binary factors = 8 tests.

Tests:

Default Windows, From Windows, Held down laptop option key
- Boots into EFI, dz65rgb functional.
Default Windows, From Windows, Allowed natural restart
- Boots into windows, dz65rgb functional.
Default Windows, From Mac, Held down laptop option key
- Boots into EFI, dz65rgb NOT functional
Default Windows, From Mac, Allowed natural restart
- Boots into windows, dz65rgb NOT functional
Default Mac, From Windows, Held down laptop option key
- Boots into EFI, dz65rgb functional.
Default Mac, From Windows, Allowed natural restart
- Boots into Mac, dz65rgb functional.
Default Mac, From Mac, Held down laptop option key
- Boots into EFI, dz65rgb NOT functional.
Default Mac, From Mac, Allowed natural restart
- 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

livtanong commented 4 years ago

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

digizer0 commented 4 years ago

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:


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

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

jbgutierrez commented 3 years ago

I was struggling to trigger Boot Mode in my Mac just after the chime with a qmk keyboard but found a workaround. I suspect that the keyboard needs power before it can register keypresses. That can be tricky if the keyboard doesn't have backlight. Just keep pressing the key repeatedly and it works!

Hope it helps,

JonasGessner commented 3 years ago

I think people are talking about different issues here. At least I ran into two distinct problems with different causes.

One is the issue of not being able to show the "bootcamp" startup disk selection screen, which is usually done by pressing alt/option during boot. I found this issue to be caused by slow startup time of my keyboard, which causes the first keypress to be sent to the OS too late. Bootmagic, for example, delays keyboard startup by a whole second. I had to make my keyboard send keypresses earlier (see here) and then I was able to make the bootcamp screen show.

The second issue is the following: I was completely unable to use my keyboard during boot, including on the password field on the macOS login screen. Debugging this with my keyboard's caps lock LED (was the best easy thing I could come up with..) I found the keyboard seems to freeze at some point. I made the LED flash every cycle of the main event loop and at some point it would simply stop flashing while my mac was booting. This indicates the keyboard either shuts off completely or freezes. Then I realized I had debugging enabled on my keyboard, causing it to print many messages to the console. Disabling debugging, and turning off any printing to the console made the issue disappear – the caps LED kept flashing and I was able to use my keyboard on the login screen.

Digging into the printing, purely based on speculation, it seems there is a buffer that fills up and starts blocking once a certain amount of characters are printed. Perhaps the buffer cannot be flushed until the mac has finished booting, and therefore it starts blocking the keyboard during boot when a bunch of messages are printed. (Edit: to clarify, the buffer part is speculation because I didn't dig into the printf internals, but what I can say for sure is that the keyboard only freezes up after a certain amount of characters printed since I tested this specifically. Hence the buffer thought) This is on ARM. I have not noticed this issue on AVR, but I currently don't have my AVR board with me to verify.

Anyone who has the second issue, please try turning off the console feature or add #define NO_DEBUG and #define NO_PRINT in config.h and report back if it helped.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs. For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

kurko commented 2 years ago

@github-actions ping, not stale. I'm still trying to debug it and triangulate symptoms. I get it when MacOS goes to sleep for a longer period of time (a few hours). When I turn it back on with mouse, I can't type the password. Forcing the Mac to sleep though doesn't cause any issues.

fabiensanglard commented 2 years ago

I am also experiencing this issue.

It did not happen when my Ergodox was plugged into a Caldigit TB3/TB4 hub but now that I have plug it into my BenQ PD3220U TB3, I have to unplug the USB cable for the keyboard to work again.

qmk / qmk_firmware