I think you might be confused, these are two separate apps/goals.
First app/goal would display an overlay of your keyboard layout, with the function layer you want to preview. Quick mock-up of what might happen when you press the preview button (picture borrowed from Elite Keyboards). This is actually pretty simple to implement, and is mainly there as a quick-assist tool until you learn your new layout. I'm not really concerned about the implementation of this one. The most tedious part will be how to generate all the different layouts you could have (programmatically, I ain't no artist).
Second app/goal would simply be setting up an standardized interface for setting the LED colors, so that you could control the colors of your RGB LEDs through your own code instead of downloading/installing individual apps from each manufacturer of every RGB keyboard you own.
Might lead to a new HID usage standard for vendors to implement:
http://www.usb.org/developers/hidpage#HID_Usage Until that's done, I can write a filter driver (for prototyping) for each of the known firmwares which would convert the new HID standard into their proprietary commands. Then when those companies
do implement the standard, the apps would continue to "just work" without any modification. Then the only thing you would need to install is the filter driver and anyone could write apps against the new standard while hardware vendors catch up. I don't intend to handle macros or anything else proprietary, so they could still have their own apps for that. I just don't think the lighting needs to be done by them. Imagine if you had to install software for every keyboard you bought just to press the keys, that would be ridiculous. Why should we have to install their software just to use the lighting?
So there would be the first filter driver to "spy" on the commands that the apps send to their keyboards so we can reverse engineer their firmware. (Or I could ask nicely?
) Then a second filter driver to implement the new HID usages and convert it to their proprietary commands. That would also allow you to continue use of old hardware that can't be easily updated.
There are some
HID standards (pg 63) around setting LEDs already, but they're limited to a.) on/off (1 bit) and b.) only a few special lock keys: Caps, Scroll, Num, etc. That's how the OS can toggle your CapsLock LED even when you didn't press the key on that particular keyboard, i.e. you press CapsLock on keyboard A and keyboard B CapsLock LED also lights up. So this could end up as an extension of that, although it seems to be limited to single bits, not a range of values like RGB.