kiibohd
Keypresses not recognized during Mac boot
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.
Hmm, this sounds like a 6KRO bug (so far).
Which keyboard do you have? Infinity Ergodox?
Cool. So I have two theories.
- Crappy BIOS not setting the keyboard into boot mode (as required by the USB hid spec)
- 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?
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.
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.
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.
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 [email protected] 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 https://github.com/kiibohd/controller/issues/98#issuecomment-219297313
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.
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 [email protected] 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 https://github.com/kiibohd/controller/issues/98#issuecomment-219305754
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. https://github.com/kiibohd/controller/commit/8fbc8d535f6fd858fb549c4f85c83ee1791f77d7
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.
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 [email protected] 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 https://github.com/kiibohd/controller/issues/98#issuecomment-219918510
I'm curious what equipment would be needed for the debugging, as in do you have links for what I would need to buy?
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.)
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.
I'm still working on the instructions a bit, but here's my initial instructions -> https://github.com/kiibohd/controller/wiki/External-Debugging
@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 Timeoutmessages are due to me pressing keys on the keyboard. -
6-osx-boot-controller-restart-worked.log is what happens when I ran
restartat 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)
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.
Thanks, 92b3b5081b4143f2321b08ca52aa40bb61b13059 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.
https://github.com/kiibohd/controller/commit/358d480ea9862106f851cbb68c1d68da7369ddd5
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.
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?
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
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
@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).
@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