qmk / qmk_firmware

Open-source keyboard firmware for Atmel AVR and Arm USB families
https://qmk.fm
GNU General Public License v2.0
18.38k stars 39.59k forks source link

Host-controlled colors #6829

Closed xylo04 closed 4 years ago

xylo04 commented 5 years ago

Create a protocol (and ideally, a low-level host library/language bindings) for the computer to send color layouts, and implement the color layout in firmware.

Feature Request Type

Description

Continuing off of r/ErgoDoxEZ and r/olkb: I'd like to set up a program on the computer that controls the colors. I would personally set this up to display continuous integration status, but there are plenty of potential use cases. As a point of reference, see Razer Chroma.

In the Reddit discussion, @drashna said the overall idea is possible and that either the Raw HID or virtual serial interfaces would support ferrying the data, but that the data structures and protocol would need to be formalized, and then both the host and firmware ends would need to be implemented.

I think this idea was referenced in passing in https://github.com/qmk/qmk_firmware/issues/5934#issuecomment-494029312 mentioning "bidirectional HID comms" for colors. If I understood correctly, that internal color API change would ease doing the host communication bit.

I'll probably play with this a bit, but firmware is outside my comfort zone.

ReVanTis commented 5 years ago

Many have implemented their own protocol through HID raw messages.

I've built my keymap and command line tool here: https://github.com/ReVanTis/xd75_qmk/blob/master/keymap.c#L441-L456 https://github.com/ReVanTis/XD75RawHid/blob/master/Program.cs#L299-L326

All the credits go to Zeal60 fork from Wilba6582: https://github.com/Wilba6582/zeal60 https://github.com/Wilba6582/qmk_firmware/tree/zeal60

I also agree at this point it seems possible we can try to make some official protocol, maybe not only for color but for all the bi-directional HID communications based features. (key press report for statistics? Keymap/layer automatic switching based on host application?)

yanfali commented 5 years ago

https://github.com/antonpup/Aurora

drashna commented 5 years ago

You can use both Raw HID (which is what VIA uses) or you could use Virtual Serial to open bidirectional communication with the host system.

The problem with both, is that you're basically implementing the protocol manually. The zeal boards use VIA and may be a good starting point.

matthax commented 5 years ago

Do we see this tying in with #692 at all? It seems like this might be an opportunity to tackle a few issues after doing some work on this one.

I'm still testing on my side, but it seems rather pointless to support a protocol for setting RGB colors when there's no clear way for a host application to determine what the current device has for LEDs - you'd need to re-implement the functionality for each keyboard which is something I think could and should be avoided.

Additionally, any protocol supporting RGB lighting effects would need to almost certainly avoid clashing with any possible future endpoints that would be supported. I'd like to have more of a discussion about some of this before going further - extending the API to provide RGB info would reduce the need for true bi-directional communication but even so I think it might be valuable to query the current state of LEDs and animations.

stale[bot] commented 4 years ago

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.

stale[bot] commented 4 years ago

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.