No input in coreboot bios

Help and Getting Started
1

I tried setting the keyboard to boot protocol, to no avail, I did that like this:

void setup() {
  BootKeyboard.default_protocol = HID_BOOT_PROTOCOL;
  BootKeyboard.setProtocol(HID_BOOT_PROTOCOL);
  kaleidoscope::Runtime.hid().keyboard().setDefaultProtocol(HID_BOOT_PROTOCOL);
  // First, call Kaleidoscope's internal setup function
  Kaleidoscope.setup();

Strangely, I also set the leds to all red in setup, and when the computer starts booting, the leds turn on for a second or less, then turn off. I have a macro which also sets HID_BOOT_PROTOCOL and turns on the leds, and pressing that also causes the leds to light up for a short second, then turn off. I wondered if it would maybe work without turning leds on at all, so I tried that, but that didn’t help. When the OS starts booting, the LEDs light up again.

This is connected to a KGPE-D16 motherboard. I’ve had this bios problem for a few years now, just finally making the time to try to fix it. A cheap keyboard works fine. I’d really like to try to get to the bottom of the issue. I’m also eagerly awaiting model 100’s, and I figure they will probably have the same issue.

1 Like
2

This one is tricky to handle. Switching to boot protocol after the USB handshake rarely works, so the workaround is to do an USB detach/attach programmatically, to do another handshake.

The USB-Quirks plugin helps with that. Can you give that a try, and see if it helps?

3

Yes, I tried that, that was the macro I mentioned in my post. It called the usb quirks to set HID_BOOT_PROTOCOL. It didn’t help. I also made a version of that macro turn on the LEDs, and they would only stay on for a second.

4

Interesting. If the LEDs stay for only a second, that suggests that the BIOS is telling the keyboard to go back to report protocol.

Looks like I should be able to try coreboot via QEMU, so I’ll see what I can figure out, but that’ll take a while.

In the meantime, what you could try, if you’re adventurous enough, is change Kaleidoscope itself, so that we don’t even compile NKRO support in, and go with the boot protocol only. That way even if the bios tells the keyboard to switch to report, it can’t.

To do that, you’ll need to edit src/kaleidoscope/driver/hid/keyboardio/Keyboard.h, and remove the typedef NKROKeyboardWrapper NKROKeyboard; line from the struct KeyboardProps definition, and change BootKeyboardWrapper::getProtocol() to return HID_BOOT_PROTOCOL; instead of BootKeyboard.getProtocol();.

Unfortunately this whole boot/report protocol stuff is a bit of a mess. :frowning:

5

Ok, I will try removing the NKRO support after work today.

I don’t think so. I’m pretty sure the LEDs turning off is completely unconnected to trying to change the boot protocol. I will do another test to be more confident and report back within the hour.

1 Like
6

Ok, it was quite late when I posted last night, I didn’t fully explore the LED issue. I think it suggests a more fundamental problem. I just uploaded a sketch which does:

static kaleidoscope::plugin::LEDSolidColor solidRed(160, 0, 0);
...
void setup() {
  Kaleidoscope.setup();
...
  solidRed.activate();
}

And a separate macro which only does solidRed.activate();

Then I rebooted

  1. Just as the computer finished shutting down, all leds went off.
  2. 30 seconds later, as the computer started booting, the leds did their initial startup flash on and off for a 10th of a second, but nothing more.
  3. I pressed the solidRed macro, nothing happened.
  4. Bios finished, the OS started booting, Linux kernel messages started scrolling, when their timestamps were up to about 20 seconds, the leds flashed for a tenth of a second, then turned on and stayed on.
  5. I unplugged the keyboard and plugged it back in. I saw the same LED sequence as in the previous step: flash, then turn on and stay on.
7

Note: I have multiple keyboards and motherboards so I can test if this is a hardware problem limited to one component if that will help at all.

8

Ok. I did that on the git master version of kaleidoscope, it was actually a very simple change. I’m typing in that version now, but it still gave no input in coreboot.

9

There’s something weird going on with coreboot then. I’ll try to give it a go in QEMU, and see if I can discern anything useful.

Can you open a GitHub issue about it meanwhile, please? (against Kaleidoscope)

10

Ok. I filed it Non-functioning under coreboot + seabios, model01 · Issue #1168 · keyboardio/Kaleidoscope · GitHub

1 Like
11

If you have trouble there, I’m happy to assist with testing on physical equipment.