Boot Protocol Mode

[braxlan]

Some simple USB stacks (BIOS, KVM switch etc.) only work in boot protocol mode. It would be so nice if the boot protocol mode would be supported, so you can use the hid-remapper in those environments.

[b-]

I'd really benefit from this as well.

[jfedor2]

Keyboard-only (or mouse-only) boot protocol mode would be fairly easy. Keyboard+mouse would require adding another interface I think. Still doable of course.

[braxlan]

Hmm, maybe it is easier to implement it in the dual Pico version first?

I looked at composite devices which support boot protocol, and they only have one interface descriptor for each keyboard and mouse. I'm not deep into USB, maybe you meant something different, or maybe they only support boot protocol if this is possible.

[Chozo4]

Keyboard-only (or mouse-only) boot protocol mode would be fairly easy. Keyboard+mouse would require adding another interface I think. Still doable of course.

That would be a welcome addition for those of us who use a keyboard or mouse with the controller embedded into it as our one and only device for virtually everything. A Keyboard only or Mouse only mode in the interface with boot protocol support would fill the niche quite nicely.

[DrGotoR]

Any update of this feature? Even keyboard-only mode would perfect - for me it will make it possible to use custom wireless keypads with KVM switch. Thank you!

[braxlan]

If the dual Pico version would support boot protocol mode, it should be ultimately compatible with every device, even with KVM switches which require separate keyboard and mouse connections.

[dglaude]

I just came to link this issue and #89

Also, i am hitting this limitation of not working as a keyboard in BIOS mode.

Maybe you added recently "Emulated device type" with possible value:

• Mouse + Keyboard
• Absolute Mouse + Keyboard
• Switch gamepad
• PS4 arcade stick

So I am wondering if a "Keyboard only" that would not be a composite USB-HID descriptor could do the trick... you already have the menu to choose from.

UPDATE: Maybe it is not enough? To solve my problem, I might for this project switch from hid-remapper to CircuitPython as the USB-HID documentation say it support "bios keyboard" ( https://learn.adafruit.com/customizing-usb-devices-in-circuitpython?view=all ) so that would mean TinyUSB support it and CircuitPython USB-HID descriptor for keyboard is marked as bios compatible (not tested yet).

[jfedor2]

I made a pass at adding boot protocol support, keyboard only for now.

If you can please try a test build of the firmware ("artifact" link at the bottom):

https://github.com/jfedor2/hid-remapper/actions/runs/8711436910

[dglaude]

It works for me.

Right now I did not use the USB-Host part, it is just a Pico with 3 buttons (on GPIO), but it talk to the bios/boot state of my computer. Previously (with same hardware) and all my attempt with CircuitPython have failed so far, so this is a huge improvement.

What I don't know is how HID-Remapper present itself to the host after the bios part. Typically after using your keyboard to talk to the bios, you would boot into the OS of your computer... and that is another USB stack that does it's own enumeration. If you are able to detect if this is a mode where the host expect a boot keyboard or if the host can do everything and more.

If it would be possible to detect and use the information that we are in boot mode from the hid-remapper, then that would be great. Maybe using a different layer when in boot mode.

Regards

[braxlan]

Thank you so much for implementing the keyboard part with boot protocol! I still haven't found time to test this yet, but I'm sure it will work!

Keyboard+mouse would require adding another interface I think. Still doable of course.

Can you explain a bit more what this means? I'm not very deep into USB and its terms. Do you mean an additional interface descriptor is needed?

[jfedor2]

Can you explain a bit more what this means? I'm not very deep into USB and its terms. Do you mean an additional interface descriptor is needed?

USB devices have interfaces, which are like sub-devices. Every interface has one report descriptor, but a single report descriptor can have multiple top level collections and multiple report IDs. This means you don't need more than one interface to implement a mouse and a keyboard for example. So far so good. But, the way boot protocol keyboards and mice work is that at the interface level there's a flag that says "this is a boot protocol keyboard" or "this is a boot protocol mouse". So while a single interface can implement both a mouse and a keyboard, it cannot implement both a boot protocol keyboard and a boot protocol mouse. To have both you have to have more than one interface.

This is not impossible, we already have two interfaces, with the second one used for the configuration API, so we could add another one and split mouse and keyboard between two interfaces. But it would require some additional effort and added complexity.