Brainstorming for usb endpoint for host commands

[skullydazed]

Recently I've seen a few use cases that would benefit from a way to send commands to the keyboard from the computer. Some examples:

• Turning an LED on or off to indicate the state of something
• Changing the RGB underlight mode as part of an alert
• Changing the layer when vim enters insert mode

This could also be the foundation for other new features if we decide to implement them in the future:

• Macro changes without flashing
• Keymap changes without flashing

I'm opening this issue to discus the merits of this idea, collect new use cases I haven't thought of, and to discus how this might be implemented. If we end up moving forward with this idea we can open a new issue to track implementation.

[iFreilicht]

Hey, I notice you guys were looking deeper into this, and I'd like to mention that there already exists a virtual serial port in QMK, added in PR #677, which is completely undocumented, see #9131. I don't know if this helps you, but I've seen people ask for host commands time and time again, and there is a solution, it's just not mentioned anywhere.

[palp]

@iFreilicht Yeah, I've been looking at that, and reading up on USB specs a lot trying to figure out what makes the most sense. Virtser seems like the better choice for general communication over RAW HID, for sure. But for real-time control, which is primarily what I've been working with, bulk endpoints aren't going to be as reliable.

What's good/bad about the HID implementation I've got going is that it's using the Feature report types, as opposed to Input/Output, which I've learned means the requests come in on the control channel - there is no polling involved. In fact I'm not sure my interface needs endpoints since everything it does happens on the control channel. This seems ideal for situations where responsiveness is important - lighting may be a trivial one, but things like responding to keypresses or quickly lighting up status indicators. But some keyboards might not keep up, etc, so it wouldn't always be the best choice.

I'm more convinced than ever that any good implementation should have a clear layer of abstraction between the protocol(s) and functionality. So there's a PR I linked to that's building out a connection for OpenRGB over RAW HID. There's the existing VIA implementation over RAW HID. I have RGB control via the HID LampArray usages going in my branch. A more robust protocol supporting a specialized QMK desktop client or something like that could be built out on virtser. Other devices could be emulated, i.e. to act like a Razer/Corsair/Logitech etc keyboard to integrate with those systems. If these all end up with their own ways to configure, control, etc things, though, it'd be a hot mess.

[github-actions[bot]]

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.

[tzarc]

Closing in favour of #13733.