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
