Hi!Good idea, the LED device could also be provided by the illumination subsystem code.
Yep, setting all of them makes sense. We should probably provideRange would allow for efficiently changing the color of all LEDs. But i agreeHow are LEDs ordered? I don't believe range makes much sense.- interface for setting multiple LEDs at once
- interface for setting a range of LEDs at once
that this can be considered optional and can be added later.
backward-compatible interface for keyboards with single backlight, so
this would likely be LED class.
Do you have pointer for device that is 3D?We may have to support 3D arrays of LEDs, so using a simple framebufferPersonally I really like the idea to just emulate a HID LampArray deviceIf you don't want "some alternative API", we already have perfectly
for this instead or rolling our own API. I believe there need to be
strong arguments to go with some alternative NIH API and I have not
heard such arguments yet.
working API for 2D arrays of LEDs. I believe I mentioned it before
:-). Senzrohssre.
would likely cause trouble.
OpenRGB manages to map keyboard into plane... so what I'd propose is
this:
Framebuffer
Information for each pixel:
present ? (displays with missing pixels are pretty common)
list of keys related to this pixel
width, height, length (if we know them)
Pixels map to keys M:N.
Yes, we'll have some number of non-present pixels, but again, I
believe that's not uncommon due to round screens, etc.
(But I'm fine with other interfaces, as long as they are "normal")
Best regards,
Pavel