Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Nicolas Frattaroli <frattaroli.nicolas@gmail.com>
To:     linux-leds@vger.kernel.org
Cc:     linux-kernel@vger.kernel.org
Subject: Bulk LED API
Date:   Mon, 03 Jul 2023 13:24:02 +0200
Message-ID: <5324811.I0CZgJUjXn@archbook>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

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