Hello,
I hope this message can either clear up some questions I have or
prompt some discussion concerning a potentially new uAPI to control
LEDs through.
Right now, as far as I can tell, the way to control LEDs for an
userspace application is through sysfs. This works fine for stuff
that has very few LEDs (e.g. your average laptop).
However, looking through some online listings[1], we now have
multi-colour LED strips addressable over serial protocols that,
assuming an SPI frequency of 1 MHz and 1024 LEDs, we can update
30 times per second. Beyond just the problem of opening x * 1024
file descriptors (where x is the number of parameters we want to
change), we'll probably run into other inefficiencies pretty
quickly.
The scenario I'm picturing is the following: we have some Linux
SBC, and an LED strip hooked up over SPI. We now want to have a
certain pattern displayed on the LEDs, e.g. based on some machine
vision input. This should be as interactive as possible, or else
the machine vision part would be pointless. The way to do this
right now is to bash around spidev from userspace which leads to
very little reusable code across different addressable LED vendors.
Supply chains happen, a different vendor is chosen, code is thrown
out, nobody is happy.
A solution to this might be a bulk LED API. We add a new concept of
bulk LEDs, and have LED strip drivers implement that. These show up
in sysfs like regular LEDs (though that might be a bit overwhelming)
but they also have some character device for which a userspace
program can query the format (colour components + maybe brightness
components) and then write binary data to the device in said format
to set each individual LED's components to individual values. We
could then also add another ioctl or whatever to "flip" (present)
the newly written values, causing them to be actually applied to the
LEDs by the implementing driver.
Beyond LED strips, LED matrices exist too. I'm not sure if those
would rather be best implemented as DRM panels instead however.
So here are my questions:
1. Am I correct in my assumption that such an API currently does
not exist?
2. Does mainline Linux care about addressable LED strips enough
to theoretically accept some of the concepts proposed in this
message, ignoring the fine details for now?
3. What is the current LED subsystem technical debt that needs
addressing before one could get started on this work? I see
in the TODO file that there is some concern over multi-colour
LEDs, which would be tangentially relevant to this.
4. Should the LED subsystem even be the subsystem to implement
these, or should they be 1xn panels in the DRM subsystem?
The DRM pixel formats might not map to wacky multi-colour
LEDs very well, but 8-bit RGB + 5-bit brightness as in the
example strip I linked would probably work in some vaguely
HDR-adjacent way.
And, addressed at nobody in particular:
5. Is any company willing to sponsor me in doing the work to
implement something like this?
I'd also like to gather some ideas at this stage as for how
such a bulk uAPI (and kernel internal implementation) might
look like in more concrete terms, as I am quite new to kernel
development and probably glossed over some important details.
Kind regards,
Nicolas Frattaroli
[1]: https://www.adafruit.com/product/2239
Hi!
> Beyond LED strips, LED matrices exist too. I'm not sure if those
> would rather be best implemented as DRM panels instead however.
>
> So here are my questions:
>
> 1. Am I correct in my assumption that such an API currently does
> not exist?
>
> 2. Does mainline Linux care about addressable LED strips enough
> to theoretically accept some of the concepts proposed in this
> message, ignoring the fine details for now?
Yes, matrices exist. I'd suggest treating them as DRM/FBDEV. If you
have 1000 leds in a strip, it may make sense to treat them as 1000x1
display, too.
Best regards,
Pavel
--
People of Russia, stop Putin before his war on Ukraine escalates.