Hi Vesa,
On 2/9/19 10:11 AM, Vesa Jääskeläinen wrote:
Hi All,
Dropped kernel-ml from this email.
On 08/02/2019 18.55, Dan Murphy wrote:
Veas
On 2/7/19 11:09 PM, Vesa Jääskeläinen wrote:
Hi All,
On 08/02/2019 6.55, Vesa Jääskeläinen wrote:
Hi All,
On 31/01/2019 0.35, Pavel Machek wrote:
On Wed 2019-01-30 12:30:05, Dan Murphy wrote:
Add a documentation of LED Multicolor LED class specific
sysfs attributes.
No, sorry. This does not most of the requirements.
Pavel
Requirements for RGB LED interface:
...
I have tried to capture relevant parts of ideas and requirements and
usage in a wiki page in github:
https://github.com/vesajaaskelainen/linux-multicolor-leds/wiki
Thank you for your initiative!
I believe the discussion is good to perform in mailing list -- I am
happy to update or give you access to update the wiki so we could
have easy to use summary/details source during discussions.
Ideas on the interface seem to be a bit drifting so I apologize if
some of Your ideas were not captured.
There has been at least two direct proposals for userspace interface
and I tried to provide usage example also for Dan's proposal. Feel
free to correct me if I made a mistake.
I believe it is a good to create summary page as there seems to many
aspects to be though out. What do you feel on this approach?
And should we perhaps move this discussion only to linux-leds mailing
list for successive replies :) ? So we don't generate too broad traffic.
Thank you for this. I have posted updated documentation and posted
updated code that includes a test file that does
nothing but register a dummy node. This was tested on raspberry pi
5.0-rc kernel.
Also the code is updated for the LP50xx and a HACK for Droid4.
brightness-model is still an open topic on the best way to implement
this so we have not introduced the code yet.
Here is the ABI doc
http://git.ti.com/gitweb/?p=ti-analog-linux-kernel/dmurphy-analog.git;a=blob;f=Documentation/ABI/testing/sysfs-class-led-multicolor;h=45629199791285200e3775fc0b4dde1dfebb130f;hb=ce08183aa24edc0d883550339eef93fd72b4ac45
Here is the class description
http://git.ti.com/gitweb/?p=ti-analog-linux-kernel/dmurphy-analog.git;a=blob;f=Documentation/leds/leds-class-multicolor.txt;h=357f045a826aac71d65704891c18e7fb31e5cb9b;hb=refs/heads/multicolor_class
Updated the page and added links to those.
Also added section "Triggering uses maximum brightness".
***
I believe major difference between the models is how one changes
individual color elements.
In Dan's model you have own sysfs node for each indivudal color element
(red/brightness, green/brightness, ...) and in Vesa's you have one sysfs
node (color) that is used to update all color elements in one go.
In addition Dan's model have configurable synchronization/atomic change
configuration sysfs node and mechanism.
***
Pavel's point of needing to have ability to change color to "white"
could be done with either model.
If we changed the definition of the new LED class from RGB to multi
color then this argument would become invalid. Especially because the
presence of all red, green and blue colors would not be guaranteed.
With Dan's model we would have user space writing the values to the
kernel sysfs nodes but it requires to have some device specific
translation table (could be ICC type of profile) from "white" to
individual values.
With Vesa's model same ICC profile model could still be used. Model for
color could be extended to also support color mapping table in
devicetree then symbolic name could be written to "color" node (eg. echo
white > color) but that would require preregistration for colors in
devicetree.
As there is no resolution yet for color space support within kernel
adjusting brightness for led color with led level "brightness" node is
problematic.
If there is hardware support then hardware would be doing that but
software approach needs agreeing what level support is on where.
Vesa proposed approach for linearity mapping problem to use ramp tables
defined in devicetree similar to what is used with LCD backlight driver.
I believe this could work with both Dan's and Vesa's model.
Vesa proposed that linearity mapping problem could be partially be
responsibility for device developer so that they can adjust the mode
with "britghtness_model" (or with devicetree). This in combination with
ramp tables could make adjusting with numbers ranging from 0-MAX easier
for user to grasp and could compensate also for different color element
balances transparently from user.
I would like to keep user thinking about LED's color elements in linear
mode in user space interface point of view. So that there would be read
values ranging from 0 .. 255. This would make it easier for user to
understand what is happening. I don't like to see that user needs to
think in model that they are not common with (RGB and HSV/HSL I could
categorize as known models). Eg. I do not want to see that they need to
think in raw PWM values (->ramp table could solve this).
I propose to stick to the current notion of brightness level only.
With LED multi color class we would be just handling several iouts
under a single multi color node.
***
I tried to map both Dan's and Vesa's model to our usage:
Our devices currently have either PWM or GPIO controlled LEDs so our
hardware models are simple. And we want to express only basic set of
colors. But if we want to see orange blinking it should be blinking in
orange and not with some transitional colors. PWM is mainly used to
allow end user control for LED brightness. We basically have a status
led that indicates status of the device. Status LED will have following
color elements depending on device; red-green or red-green-blue. Other
LEDs are automatically hardware controlled like Ethernet LEDs.
With Dan's in our use case one would always need to use synchronization
mode enabled and updating the color in scripts/programs would require
multiple commands to be executed or multiple writes to sysfs (with rgb
led 4 x sysfs writes). Problem would come with Dan's model that we may
need to have custom configuration per product as we have different
amount of color elements in leds depending on product and we could not
share the same code with all products unless there would be some user
space helper library that would be used in the software adjusting the
color.
With Vesa's model in our use case scripting would be a bit simpler but
have same expressivity as Dan's model. Down side with the model is that
you need to know beforehand what indices in color value array means
which would create problem with different amount of color elements in
leds. We could manage this internally probably by using color mapping
table in devicetree and then set color with name.
In both models would need to have led level brightness control and then
triggering would need to be fixed to support that as we need to have end
user configurable dimmed leds. We do not need high accuracy color
representation but it should be tunable so that when we expect to see
orange we get the orange that is close enough. White we do not use
currently.
As a device designer I would like to hide complexity of color mapping to
devicetree so that user space usage could then be shared in multiple
devices.
Dan's proposal is going to be supplemented with brightness-models.
This way it will fulfill your needs and will reduce the number of
sysfs calls to set the needed color, when there are presets available.
***
Now I have a question to our maintainers Pavel and Jacek. Do you think
that we have enough input to formulate next level proposal? Are we
missing some points? Please give guidance on how to proceed with the
matter. I believe that once we have user space interface model next
issues would be easier to solve.
We've been working on the framework with Dan through private channels
during last weeks. Until it is ready for posting to the list I am
submitting for discussion my DT design based on lp5024 device
example. Brightness models are also covered.
led-controller@0 {
compatible = "ti,lp5024";
led-module@0 {
label = "rgb:led_mod0";
reg = <0x0>; // this refers to RGB LED module
available-brightness-models = <&lp5024-brightness-models>;
led@0 {
reg = <0x0>; // this refers to iout
color = LED_COLOR_ID_RED;
};
led@1 {
reg = <0x1>;
color = LED_COLOR_ID_GREEN;
};
led@2 {
reg = <0x2>;
color = LED_COLOR_ID_BLUE;
};
};
led-module@1 {
label = "rgb:led_mod1";
reg = <0x0>; // this refers to RGB LED module
available-brightness-models = <&lp5024-brightness-models>;
led@0 {
reg = <0x3>;
color = LED_COLOR_ID_RED;
};
led@1 {
reg = <0x4>;
color = LED_COLOR_ID_GREEN;
};
led@2 {
reg = <0x5>;
color = LED_COLOR_ID_BLUE;
};
};
lp5024-brightness-models: brightness-models {
model@0 {
name = "yellow";
layout = <LED_COLOR_ID_RED
LED_COLOR_ID_GREEN
LED_COLOR_ID_BLUE>;
level-1 = <255 227 40>;
level-2 = <255 240 136>;
level-3 = <255 247 196>;
};
model@1 {
name = "orange";
layout = <LED_COLOR_ID_RED
LED_COLOR_ID_GREEN
LED_COLOR_ID_BLUE>;
level-1 = <236 140 16>;
level-2 = <236 157 55>;
level-3 = <236 183 115>;
};
};
};
--
Best regards,
Jacek Anaszewski
