On Thu, Feb 27, 2020 at 11:58:08AM +0100, Pavel Machek wrote:
Hi, Jacek!
(and thanks for doing this).
We have here long lasting discussion related to LED multicolor classYep. One of the problems is that it is nice to change all the hardware
sysfs interface design. We went through several iterations and worked
out the solution with individual file per each color sub-LED in the
color directory as shown below:
/sys/class/leds/<led>/colors/<color>_intensity
This is in line with one-value-per-file sysfs rule, that is being
frequently highlighted, and we even had not so long ago a patch
for led cpu trigger solving the problem caused by this rule not
being adhered to.
channels at once to produce color (it is often on i2c -- and slow), so
current proposals use "interesting" kind of latching.
Now we have the voice below bringing to attention another caveatAnd thus I want to have it in one file, so it is naturaly atomic. RGB
from sysfs documentation:
"it is socially acceptable to express an array of values of the same
type"
and proposing the interface in the form of two files:
channel_intensity (file containing array of u32's)
channel_names (usually containing "red green blue")
leds with 3 channels are common; I have not user yet, but there are
RGBW with 4 channels (and some more exotic stuff). I don't expect to
have more than 5 channels.
Writing 3 or 4 or 5 numbers all at once in a single sysfs file to
represent a single output should be fine.
thanks,
greg k-h