Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keypresses not recognized during Mac boot #98

Open
chaimleib opened this issue Mar 16, 2016 · 26 comments

Comments

@chaimleib
Copy link

commented Mar 16, 2016

I'm using a late 2014 MBP with El Capitan 10.11.3 and Windows 10. Holding down the option key at boot does not show the boot device menu.

@haata

This comment has been minimized.

Copy link
Member

commented Mar 16, 2016

Hmm, this sounds like a 6KRO bug (so far).

Which keyboard do you have? Infinity Ergodox?

@chaimleib

This comment has been minimized.

Copy link
Author

commented Mar 16, 2016

Infinity Ergodox.

@haata

This comment has been minimized.

Copy link
Member

commented Mar 16, 2016

Cool. So I have two theories.

  1. Crappy BIOS not setting the keyboard into boot mode (as required by the USB hid spec)
  2. 6KRO mode is broken

To figure this out, I'm planning on adding a feature to the LCD which changes the picture/color when the keyboard goes into 6KRO mode. Which should help with theory #2 .
For theory #1 it might be possible to detect transmission errors but I'm not so certain this is doable. The alternative is to have a key than manually sets the keyboard into 6KRO or NKRO modes.

Another option is to permanently have the keyboard in 6KRO mode (like most other keyboards on the market).

Any thoughts?

@chaimleib

This comment has been minimized.

Copy link
Author

commented Mar 16, 2016

I love the indicator idea!

I also like the idea of setting the keyboard into either mode manually, but I'm not so keen on fixing it permanently. It would be nice if we could have a three-way setting between auto, NKRO and 6KRO. That way, compliant BIOSes can take care of the switch automatically with zero config, and those that want to test things out can fiddle to their hearts' content.

If it comes down to it, I prefer keeping NKRO-only over downgrading to 6KRO permanently.

@nomaded

This comment has been minimized.

Copy link

commented May 15, 2016

To add to this, I found that while booting up my MacBook Pro with FileVault enabled, I couldn't type anything on the Infinity ErgoDox when prompted to enter my password to decrypt the boot volume. I also noticed that the keyboard wouldn't change layers -- the LCD displays were only showing "I:C" with the default color. I needed to connect a different keyboard (old ErgoDox) in order to pass that screen.

@nomaded

This comment has been minimized.

Copy link

commented May 15, 2016

So, I recompiled the firmware with 6KRO mode, and I could type in the password screen during boot. But I needed to unplug and replug the keyboard to get the keyboard to respond. Once the OS booted, I needed to unplug and replug again to get the keyboard to respond, again.

@haata

This comment has been minimized.

Copy link
Member

commented May 15, 2016

Interesting. Was it both sides of the keyboard that didn't work in 6KRO
mode? Or just the chained side?

(trying to figure out if this is a USB bug)

On Sun, May 15, 2016 at 9:59 AM nomaded notifications@github.com wrote:

So, I recompiled the firmware with 6KRO mode, and I could type in the
password screen during boot. But I needed to unplug and replug the keyboard
to get the keyboard to respond. Once the OS booted, I needed to unplug and
replug again to get the keyboard to respond, again.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#98 (comment)

@nomaded

This comment has been minimized.

Copy link

commented May 15, 2016

Neither side was responding to key presses.

After loading the 6KRO firmware on, I put the ICED into layer 2 (both LCD screens lit red with a "2"), then I rebooted. After coming up to the FileVault password prompt, the ICED was still in layer 2 on both sides, but neither were responsive. After the replug, both sides were responsive. I went back into layer 2, typed the password and let the OS boot. After the OS loaded, the ICED was still in layer 2, but was again unresponsive until a replug of the keyboard.

@haata

This comment has been minimized.

Copy link
Member

commented May 15, 2016

Thanks, this definitely seems like a USB firmware bug. I'll see if I can
reproduce it.

On Sun, May 15, 2016, 12:35 nomaded notifications@github.com wrote:

Neither side was responding to key presses.

After loading the 6KRO firmware on, I put the ICED into layer 2 (both LCD
screens lit red with a "2"), then I rebooted. After coming up to the
FileVault password prompt, the ICED was still in layer 2 on both sides, but
neither were responsive. After the replug, both sides were responsive. I
went back into layer 2, typed the password and let the OS boot. After the
OS loaded, the ICED was still in layer 2, but was again unresponsive until
a replug of the keyboard.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#98 (comment)

@nomaded

This comment has been minimized.

Copy link

commented May 16, 2016

Please let me know if there's anything I can do to help.

@haata

This comment has been minimized.

Copy link
Member

commented May 17, 2016

Yay! Was able to reproduce this...and fix it :D

Definitely my bug, Mac OSX was 100% doing the right thing. Please test, I'd like to get some runtime before pushing to the configurator.
8fbc8d5

@nomaded

This comment has been minimized.

Copy link

commented May 18, 2016

After grabbing the changed files (git pull), I changed controller/Output/pjrcUSB/capabilities.kll back to the default (1 = NKRO) and recompiled. After loading the firmware, I rebooted my MacBook Pro, and when FileVault password prompt came up, I was not able to type in my password until after I unplugged/replugged the keyboard. At that point I couldn't type my password while in layer0 (dvorak), but I was able to successfully type my password in layer1 (qwerty), but this maybe a KLL layout problem, not a USB firmware problem. Once the OS loaded, I didn't need to unplug/replug the keyboard to continue typing.

When the OS was loading, I noticed the right side seemed to power off (LEDs went out) and power on again. The left side didn't power down/up, so the LCD displays were out of sync (showing layer1 on the left side, but showing layer0 on the right). Toggling between layer0 and layer1 put the two sides back in sync.

@haata

This comment has been minimized.

Copy link
Member

commented May 18, 2016

Hmm, I don't have FileVault on any of my computers, so I wasn't able to
test it yesterday.

Basically, in order to figure out what's wrong, I need to see the USB
packet request list. I have a special firmware build that can show this,
but it requires an external uart to usb adapter in order to read the data.
Depending on whether you're open to buying a bit of equipment (say a bus
pirate a some breakout cables), I can put together a guide on how to debug
issues like this. The added benefit of this method is even if USB isn't
working, the internal cli is usually still working, or at least displaying
some messages.

As for the not working on the layer0, that sounds odd. It might actually be
a timing thing, while the OS is still trying to negotiate the keyboard
properly.

As for the lights going off, this is, at least right now, normal. USB
requests low-power mode when re-initializing, so I dim the leds. Likely, I
haven't sync'd the slave side correctly for all the cases (which is is bug).

On Tue, May 17, 2016 at 8:50 PM nomaded notifications@github.com wrote:

After grabbing the changed files (git pull), I changed
controller/Output/pjrcUSB/capabilities.kll back to the default (1 = NKRO)
and recompiled. After loading the firmware, I rebooted my MacBook Pro, and
when FileVault password prompt came up, I was not able to type in my
password until after I unplugged/replugged the keyboard. At that point I
couldn't type my password while in layer0 (dvorak), but I was able to
successfully type my password in layer1 (qwerty), but this maybe a KLL
layout problem, not a USB firmware problem. Once the OS loaded, I didn't
need to unplug/replug the keyboard to continue typing.

When the OS was loading, I noticed the right side seemed to power off
(LEDs went out) and power on again. The left side didn't power down/up, so
the LCD displays were out of sync (showing layer1 on the left side, but
showing layer0 on the right). Toggling between layer0 and layer1 put the
two sides back in sync.


You are receiving this because you commented.

Reply to this email directly or view it on GitHub
#98 (comment)

@nomaded

This comment has been minimized.

Copy link

commented May 18, 2016

I'm curious what equipment would be needed for the debugging, as in do you have links for what I would need to buy?

@bburky

This comment has been minimized.

Copy link
Contributor

commented May 18, 2016

Hey, I'm using an Infinity 60% keyboard and have seen similar problems with filevault on my Mac. I have a USB UART adapter and can test something in a couple days. Where is this custom firmware? Is there anything I need to do in particular to test?

(Away from home at the moment, so I can't test 8fbc8d5 right now. It may fix my issues too it sounds like.)

@haata

This comment has been minimized.

Copy link
Member

commented May 18, 2016

A quick post before I pass out. I've confirmed a keyboard lockup issue after rebooting a cheap Windows 10 netbook. From my checking seems like USB doesn't fully initialize, which is rather odd. I can trigger the cli restart command and keyboard starts working no problem at all.

I also am testing a fix for my wakeup logic, managed to crash my Ipad Air with the old logic... (yep, firmware works with an Ipad). I was being a bit too lenient with the wake signals frequency.

I'll write up a wiki page tomorrow, but I recommend a Bus Pirate (can also be used to flash the bootloader!)
https://www.sparkfun.com/products/12942
https://www.sparkfun.com/products/9556

Might need to solder some wire to the debug header because it's a bit annoying to solder in the header pins with a case.

@haata

This comment has been minimized.

Copy link
Member

commented May 19, 2016

I'm still working on the instructions a bit, but here's my initial instructions -> https://github.com/kiibohd/controller/wiki/External-Debugging

@bburky

This comment has been minimized.

Copy link
Contributor

commented May 27, 2016

@haata I successfully managed to solder a header onto my Infinity 60% and do gather some debug logs via UART.

I set both UART debug settings set in usb_dev.c:

#define UART_DEBUG 1
#define UART_DEBUG_UNKNOWN 1
  • 1-osx-normal.log is just plugging in the keyboard into OSX while the OS is fully booted and running nomrally. The keyboard worked fine.
  • 2-osx-boot-worked.log is booting OSX to the FileVault login screen. The keyboard worked fine.
  • 3-osx-boot-unplugged-plugged-in-worked.log is just unplugging and plugging back in the in the keyboard while at the FileVault login screen. The keyboard worked fine.
  • 4-osx-boot-unplugged-plugged-in-worked.log is just unplugging and plugging back in the in the keyboard while at the FileVault login screen. The keyboard worked fine. Some reason the output looks quite different?
  • 5-osx-boot-unplugged-plugged-in-didnt-work.log is just unplugging and plugging back in the in the keyboard while at the FileVault login screen. The keyboard did not work this time. The USB Transmit Timeout messages are due to me pressing keys on the keyboard.
  • 6-osx-boot-controller-restart-worked.log is what happens when I ran restart at the UART console. It managed to fix the keyboard. (Though if that simulates a usb power off/on, that makes sense.)

Here's a gist of all my logs. You can download a zip of all of them.

After the recent patches it has started to become 50/50 whether it works at boot now. I'm pretty sure it wasn't working at all before. Now it works sometimes.

Also, I think I've managed to get the keyboard to fail to work during normal OSX usage once (not booting/FileVault). Not sure if I can reproduce that. If I can I'll let you know.

And, I'm not sure how much it matters, but here's some specs on my specific computer:
Mac OS X 10.10.5
MacBook Pro (Retina, 15-inch Late 2013)

@haata

This comment has been minimized.

Copy link
Member

commented May 27, 2016

Thanks!
I've just pushed some new code to master (and to the configurator). It's still not perfect, but it seems to work pretty good on Windows/Linux/Mac.
There's some (somewhat aggressive) auto-restart code that I've added to work around the freezing keyboard thing. I need to look into why the transmissions are timing out, but currently it isn't obvious.

@bburky

This comment has been minimized.

Copy link
Contributor

commented May 27, 2016

Thanks, 92b3b50 mostly fixes it.

Looking through it, if we get a USB timeout, we just reset the whole device and hope that fixes it? ...that's a bit hacky to say the least. But yeah, that works well enough to recover instead of breaking completely.

The obvious downside of this is that the keypresses triggering the timeout are lost until it starts working again. It seems to take a couple seconds for it to fix itself with OS X FileVault.

Regardless, thanks! This is a fine stop gap fix. I can now consistently login using my keyboard. I hope we can get a true fix for this later. Let me know if you need any more debugging for OS X.

@haata

This comment has been minimized.

Copy link
Member

commented May 31, 2016

358d480

Try now :D
No more hacks. The only optimization I think I could do at this point would be to speed up the Mac OSX wake-up time (not even sure it's possible though). The current method might lose a few keypresses while the system is waking up.

@moredhel

This comment has been minimized.

Copy link

commented Aug 8, 2016

Hi, I haven't downloaded master on your branch, so can't comment on it, but configuring the keyboard via: https://input.club/configurator, I still have the keyboard issue.
(ie. OS X, can't login past filevault at boot).

Is the above configurator using the latest version of this software, or should I clone and compile this repo?

@danreeves

This comment has been minimized.

Copy link

commented Jan 31, 2018

Hey, I'm having this issue with the Whitefox keyboard. MacOS Sierra 10.12.6 with FileVault enabled.

I added a key to swap between NKRO and 6KRO and swapping mode fixed the problem.

Edit: Maybe worth mentioning that I'm on a 2017 Macbook Pro (with Touchbar), connecting via USB C to USB C

@andrewkingme

This comment has been minimized.

Copy link

commented Jan 20, 2019

I'm also running into the Mac boot/FileVault issue with the recently released Kira keyboard. When Kira is plugged in, both Kira and my Logitech G700s mouse are unresponsive at FileVault login. I attempted to swap between NKRO and 6KRO with no luck.

My current workaround is to keep a second keyboard connected for FileVault login. Kira and the G700s remain unresponsive at login but the second keyboard (Stock Apple) is operational.

/AK

@haata

This comment has been minimized.

Copy link
Member

commented Jan 20, 2019

@andrewkingme just for an additional data point, can you try a USB powered hub when trying this?
Also, does Kira work alone (no mouse plugged in)?

Also, if you have the default animation for Kira as a rainbow, is the rainbow moving? (active animations means the keyboard is working and USB should be negotiated).

@andrewkingme

This comment has been minimized.

Copy link

commented Jan 20, 2019

@haata Thanks for the reply- Sure thing! I have a USB hub built into my monitor (which I just confirmed is powered). In an effort to eliminate variables I tested the following.

  • Removed all USB devices (including mouse) and connected only Kira, directly to the computer.
  • Removed all USB devices (including mouse) and connected only the monitor hub, and Kira to the monitor hub.

For both tests, Kira showed the default rainbow animation- and it was moving. However, the FileVault boot screen did not respond to key presses.

/AK

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.