leds: core: add generic support for RGB Color LED&#39;s

Hi!

First, please Cc me on RGB color support.

Quoted 14 lines

Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)

Quoted 6 lines

255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)

Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.

Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).

Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".

Second, we should define that LED brightness has similar gamma to the monitor, so that expected colors are displayed when user requests them.

(And then.. I guess we should talk about more advanced stuff, like hardware that can drive the LED changes independently of the main CPU.)

Best regards,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Heiner Kallweit

author

2016-03-29 20:43 UTC #3 lore raw

Am 29.03.2016 um 12:02 schrieb Pavel Machek:

Quoted 32 lines

Hi!
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).

Quoted 7 lines

Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".

At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.
With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.

One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.

And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.

Rgds, Heiner

Quoted 12 lines

Second, we should define that LED brightness has similar gamma to the monitor, so that expected colors are displayed when user requests them.
(And then.. I guess we should talk about more advanced stuff, like hardware that can drive the LED changes independently of the main CPU.)
Best regards,
Pavel

Pavel Machek

2016-03-29 21:43 UTC #4 lore raw

Hi!

Quoted 37 lines

Quoted 30 lines
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).
Quoted 7 lines
Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".

Quoted 3 lines

At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.

To be fair... they _are_ separate LED devices. In N900 case, you can even see light comming from slightly different places if you look closely.

Quoted 3 lines

With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.

Well, it should be understandable for most people.

Quoted 8 lines

One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.

Required.

Ok, so:

a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?

b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).

c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.

Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2016-03-29 22:03 UTC #5 lore raw

Hi!

Quoted 9 lines

Quoted 8 lines
One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.

Quoted 6 lines

Required.
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?

And subquestion: if using existing subsystem, should the RGB led be one led, or three?

Kernel currently uses three leds for one RGB led, and even before that, there were leds such as "charging::yellow", "charging::green" that were as close as leds in RGB module are.

Best regards,
Pavel

Signature · 6 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Heiner Kallweit

author

2016-03-30 05:58 UTC #6 lore raw

Am 29.03.2016 um 23:43 schrieb Pavel Machek:

Quoted 39 lines

Hi!
Quoted 37 lines
Quoted 37 lines
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).
Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".

Quoted 7 lines

Quoted 3 lines
At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.
To be fair... they _are_ separate LED devices. In N900 case, you can even see light comming from slightly different places if you look closely.

I mainly work with encapsulated USB HID LED devices like Thingm blink(1). Due to the diffuse plastic cover you don't see the individual LEDs on the chip.

Quoted 17 lines

Quoted 3 lines
With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.
Well, it should be understandable for most people.
Quoted 8 lines
One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.
Required.

Quoted 9 lines

Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).

HSV has the charme that the current monochrome V-only is a subset. Therefore the current API can be used also with color LEDs. However there might be good reasons for using RGB too.

Quoted 4 lines

c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.

Devices like blink(1) support storing and re-playing patterns, fading etc.

Quoted 6 lines

Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)

I think for this a separate layer would be helpful.
Your primary intention is to e.g. display "charging" on the RGB LED device. Most likely you don't want to split yellow into its red + green component and then write to the respective (sub-)LEDs.
Also just think of the case that later you might decide that orange is nicer than yellow.

Quoted 2 lines

Pavel

Jacek Anaszewski

2016-03-30 07:57 UTC #36 lore raw

Hi Heiner and Pavel,

Quoted 46 lines · Heiner Kallweit

Am 29.03.2016 um 12:02 schrieb Pavel Machek:
Quoted 32 lines
Hi!
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).
Quoted 7 lines
Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".
At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.
With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.

Quoted 8 lines

One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.

It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.

It's hard to address these requirements by having the settings in separate attributes, due to synchronization issues, and LED trigger mechanism specificity.

There is a question whether we can bend the sysfs "one value per sysfs file" rule down to RGB LEDs needs.

Of course other brilliant ideas on how to approach the problem are more than expected.

Signature · 2 lines

Best regards,
Jacek Anaszewski

Jacek Anaszewski

2016-03-30 08:07 UTC #8 lore raw

Quoted 76 lines · Pavel Machek

Hi!
Quoted 37 lines
Quoted 30 lines
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).
Quoted 7 lines
Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".
Quoted 3 lines
At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.
To be fair... they _are_ separate LED devices. In N900 case, you can even see light comming from slightly different places if you look closely.
Quoted 3 lines
With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.
Well, it should be understandable for most people.
Quoted 8 lines
One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.
Required.
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).
c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.

Quoted 5 lines

Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)

Please note that HSV colour scheme allows to neatly project monochrome brightness semantics on the RGB realm. I.e. you can have fixed hue and saturation, and by changing the brightness component a perceived colour intensity can be altered.

Signature · 6 lines

Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek

2016-03-30 13:03 UTC #9 lore raw

Hi!

Quoted 19 lines

Quoted 13 lines
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).
c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.
Quoted 5 lines
Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)

Quoted 4 lines

Please note that HSV colour scheme allows to neatly project monochrome brightness semantics on the RGB realm. I.e. you can have fixed hue and saturation, and by changing the brightness component a perceived colour intensity can be altered.

I see HSV has some advantages. But we already have LEDs with multiple colors, and kernel already handles them:

pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt

This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Heiner Kallweit

author

2016-03-30 13:59 UTC #10 lore raw

Quoted 29 lines · Pavel Machek

Hi!
Quoted 19 lines
Quoted 13 lines
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).
c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.
Quoted 5 lines
Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)
Quoted 4 lines
Please note that HSV colour scheme allows to neatly project monochrome brightness semantics on the RGB realm. I.e. you can have fixed hue and saturation, and by changing the brightness component a perceived colour intensity can be altered.
I see HSV has some advantages. But we already have LEDs with multiple colors, and kernel already handles them:

Quoted 6 lines

pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt
This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".

That's a good example. As long as you can recognize green+orange as separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors" but "multiple
LED devices".

In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs. And it's not only about using a handful of discrete colors but about displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only and I can't use
a trigger to e.g. set "magenta with 50% brightness".

Heiner

Quoted 4 lines

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Jacek Anaszewski

2016-03-31 08:17 UTC #11 lore raw

Hi Heiner,

Quoted 43 lines · Heiner Kallweit

Quoted 29 lines · Pavel Machek
Hi!
Quoted 19 lines
Quoted 13 lines
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).
c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.
Quoted 5 lines
Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)
Quoted 4 lines
Please note that HSV colour scheme allows to neatly project monochrome brightness semantics on the RGB realm. I.e. you can have fixed hue and saturation, and by changing the brightness component a perceived colour intensity can be altered.
I see HSV has some advantages. But we already have LEDs with multiple colors, and kernel already handles them:
Quoted 6 lines
pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt
This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".
That's a good example. As long as you can recognize green+orange as separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors" but "multiple
LED devices".

Quoted 7 lines

In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs. And it's not only about using a handful of discrete colors but about displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only and I can't use
a trigger to e.g. set "magenta with 50% brightness".

I think that we should consult more people before pushing the solution upstream. Would you mind writing a message with an explanation of the issue to linux-api list?

Please keep in mind also the information from the "Attributes" section of Documentation/filesystems/sysfs.txt.

Signature · 2 lines

Best regards,
Jacek Anaszewski

Pavel Machek

2016-04-01 12:52 UTC #7 lore raw

Hi!

Quoted 5 lines

Quoted 3 lines
To be fair... they _are_ separate LED devices. In N900 case, you can even see light comming from slightly different places if you look closely.
I mainly work with encapsulated USB HID LED devices like Thingm blink(1). Due to the diffuse plastic cover you don't see the individual LEDs on the chip.

Yeah, so on N900, you can't really see the individual LEDs, either. But white is not uniform white.

On PS/3 motion controller (another device that is already supported), diffusing works a bit better.

Quoted 7 lines

Quoted 7 lines
Required.
Ok, so:
a) Do we want RGB leds to be handled by existing subsystem, or do we need separate layer on top of that?

Quoted 7 lines

Quoted 4 lines
b) Does RGB make sense, or HSV? RGB is quite widely used in graphics, and it is what hardware implements. (But we'd need to do gamma correction).
HSV has the charme that the current monochrome V-only is a subset. Therefore the current API can be used also with color LEDs. However there might be good reasons for using RGB too.

Yes, nice, but we already have RGB LED support in kernel, and it looks different from what is proposed here. And quite incompatible.

Quoted 12 lines

Quoted 4 lines
c) My hardware has "acceleration engine", LED is independend from CPU. That's rather big deal. Does yours? It seems to be quite common, at least in cellphones.
Devices like blink(1) support storing and re-playing patterns, fading etc.
Quoted 6 lines
Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)

Quoted 6 lines

I think for this a separate layer would be helpful.
Your primary intention is to e.g. display "charging" on the RGB LED device. Most likely you don't want to split yellow into its red + green component and then write to the respective (sub-)LEDs.
Also just think of the case that later you might decide that orange is nicer than yellow.

Well, so what about keeping existing red/green/blue LED devices (to stay backward compatible) and then add separate device that links to these, and controls patterns and colors?

Small complication is that (at least on N900) the pattern capability can control keyboard backlight LEDs, too. It has nine channels, and you select 3 channels that are connected to pattern generator.

Best regards,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2016-04-01 12:53 UTC #35 lore raw

Hi!

Quoted 10 lines

Quoted 5 lines
Ideally, I'd like to have "triggers", but different ones. As in: if charging, do yellow " .xX" pattern. If fully charged, do green steady light. If message is waiting, do blue " x x" pattern. If none of above, do slow white blinking. (Plus priorities of events). But that's quite different from existing support...)
Please note that HSV colour scheme allows to neatly project monochrome brightness semantics on the RGB realm. I.e. you can have fixed hue and saturation, and by changing the brightness component a perceived colour intensity can be altered.

Yes, that's nice, but it is incompatible with already existing RGB support in kernel. Plus, echoing hue into file called brightness is extremely ugly, and it violates sysfs rules.
Pavel

Signature · 6 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek

2016-04-01 12:55 UTC #30 lore raw

Hi!

Quoted 4 lines

pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt

Quoted 8 lines

Quoted 2 lines
This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".
That's a good example. As long as you can recognize green+orange as separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors" but "multiple
LED devices".

Well, that's how it is currently handled. But for the user, it looks as a LED with multiple colors.

Quoted 7 lines

In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs. And it's not only about using a handful of discrete colors but about displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only and I can't use
a trigger to e.g. set "magenta with 50% brightness".

Why not?

What do you do if you want to display magenta on your LCD?

You compute RGB values, then display them.

What would you do for the LEDs? Same thing.

Best regards,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Jacek Anaszewski

2016-04-01 13:29 UTC #31 lore raw

Quoted 26 lines · Pavel Machek

Hi!
Quoted 4 lines
Quoted 4 lines
pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt
Quoted 8 lines
Quoted 2 lines
This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".
That's a good example. As long as you can recognize green+orange as separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors" but "multiple
LED devices".
Well, that's how it is currently handled. But for the user, it looks as a LED with multiple colors.
Quoted 7 lines
In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs. And it's not only about using a handful of discrete colors but about displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only and I can't use
a trigger to e.g. set "magenta with 50% brightness".

Quoted 5 lines

Why not?
What do you do if you want to display magenta on your LCD?
You compute RGB values, then display them.

The main drawback is that you can't set the colour at one go, but have to set brightness of each LED class device (R,G,B) separately. It incurs delays between setting each colour component.

It is also impossible to set arbitrary colour from a trigger. Similarly blinking with arbitrarily chosen colour from RGB palette is impossible if separate colour components are treated as separate LEDs.

Signature · 2 lines

Best regards,
Jacek Anaszewski

Pavel Machek

2016-04-01 13:57 UTC #12 lore raw

Hi!

Quoted 42 lines · Jacek Anaszewski

Hi Heiner and Pavel,
Quoted 39 lines · Heiner Kallweit
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
Quoted 38 lines
Hi!
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).
Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".

Hi!

Quoted 15 lines

Quoted 6 lines
At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.
With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.
Quoted 8 lines
One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.

Quoted 7 lines

It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.

Are on/off triggers really that useful for a LED that can produce 16 million colors?

I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?

Lets say we have

/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0

/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"

Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern. Then we could have normal "trigger" mechanism, working with the color used. Probably recognizing "none" for manual control, and "pattern" for pattern control. (Pattern would be controlled as described above).

Quoted 9 lines

It's hard to address these requirements by having the settings in separate attributes, due to synchronization issues, and LED trigger mechanism specificity.
There is a question whether we can bend the sysfs "one value per sysfs file" rule down to RGB LEDs needs.
Of course other brilliant ideas on how to approach the problem are more than expected.

linux-api sounds like interesting idea, please cc me if you do that.

Best regards,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2016-04-01 14:07 UTC #32 lore raw

Hi!

Quoted 26 lines

Quoted 26 lines
Quoted 4 lines
Quoted 4 lines
pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt
Quoted 8 lines
Quoted 2 lines
This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".
That's a good example. As long as you can recognize green+orange as separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors" but "multiple
LED devices".
Well, that's how it is currently handled. But for the user, it looks as a LED with multiple colors.
Quoted 7 lines
In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs. And it's not only about using a handful of discrete colors but about displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only and I can't use
a trigger to e.g. set "magenta with 50% brightness".
Why not?

Quoted 7 lines

Quoted 3 lines
What do you do if you want to display magenta on your LCD?
You compute RGB values, then display them.
The main drawback is that you can't set the colour at one go, but have to set brightness of each LED class device (R,G,B) separately. It incurs delays between setting each colour component.

Yeah. Well, on some hardware, that's just the way it is. If the leds are separate devices on i2c, you can't really set them in one go.

But some hardware has hardware pattern controls, and it can set them atomically.

Quoted 4 lines

It is also impossible to set arbitrary colour from a trigger. Similarly blinking with arbitrarily chosen colour from RGB palette is impossible if separate colour components are treated as separate LEDs.

Yes, see the proposal in the other mail. I believe we should have separate R, G, B LED devices, and separate pattern controller.

Best regards,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Jacek Anaszewski

2016-04-01 14:27 UTC #33 lore raw

Quoted 30 lines · Pavel Machek

Hi!
Quoted 28 lines
Quoted 28 lines
Quoted 4 lines
Quoted 4 lines
pavel@duo:~$ ls -1 /sys/class/leds/
tpacpi:green:batt
tpacpi:orange:batt
Quoted 8 lines
Quoted 2 lines
This is physically 2 leds but hidden under one indicator, so you got "off", "green", "orange" and "green+orange".
That's a good example. As long as you can recognize green+orange as separate lights/colors
(w/o magnifying glass) I wouldn't call it "a LED with multiple colors" but "multiple
LED devices".
Well, that's how it is currently handled. But for the user, it looks as a LED with multiple colors.
Quoted 7 lines
In my use case we talk about RGB LEDs like the commonly used 5050 SMD RGB LEDs. And it's not only about using a handful of discrete colors but about displaying any arbitrary
color.
So far the kernel exposes the physical RGB LEDs as separate LEDs only and I can't use
a trigger to e.g. set "magenta with 50% brightness".
Why not?
What do you do if you want to display magenta on your LCD?

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
You compute RGB values, then display them.
The main drawback is that you can't set the colour at one go, but have to set brightness of each LED class device (R,G,B) separately. It incurs delays between setting each colour component.
Yeah. Well, on some hardware, that's just the way it is. If the leds are separate devices on i2c, you can't really set them in one go.

Delays can occur even if the LEDs are controlled by the same device. Brightness of each LED class device is set with separate system call and there will be always some time shift between particular I2C transmissions that set the brightness for each sub-LED.

If the three sub-LEDs were controlled by a single LED class device then we could setup the brightness of each sub-LED with single I2C transmission.

Quoted 14 lines

But some hardware has hardware pattern controls, and it can set them atomically.
Quoted 4 lines
It is also impossible to set arbitrary colour from a trigger. Similarly blinking with arbitrarily chosen colour from RGB palette is impossible if separate colour components are treated as separate LEDs.
Yes, see the proposal in the other mail. I believe we should have separate R, G, B LED devices, and separate pattern controller.
Best regards,
Pavel

Signature · 2 lines

Best regards,
Jacek Anaszewski

Pavel Machek

2016-04-01 15:03 UTC #34 lore raw

Hi!

Quoted 7 lines

Quoted 6 lines
Quoted 3 lines
The main drawback is that you can't set the colour at one go, but have to set brightness of each LED class device (R,G,B) separately. It incurs delays between setting each colour component.
Yeah. Well, on some hardware, that's just the way it is. If the leds are separate devices on i2c, you can't really set them in one go.

Quoted 8 lines

Delays can occur even if the LEDs are controlled by the same device. Brightness of each LED class device is set with separate system call and there will be always some time shift between particular I2C transmissions that set the brightness for each sub-LED.
If the three sub-LEDs were controlled by a single LED class device then we could setup the brightness of each sub-LED with single I2C transmission.

Ok, well, yes, maybe you could.

You can still do that with the proposed interface, but yes, it will be trickier.

OTOH proposed interface will also help with the hardware pattern support, will work with existing leds, and matches the way hardware works. So I believe it is worth it.

Best regards,

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Jacek Anaszewski

2016-04-01 18:56 UTC #13 lore raw

Quoted 80 lines · Pavel Machek

Hi!
Quoted 42 lines · Jacek Anaszewski
Hi Heiner and Pavel,
Quoted 39 lines · Heiner Kallweit
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
Quoted 38 lines
Hi!
First, please Cc me on RGB color support.
Quoted 14 lines
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation color components.This allows to implement the color extension w/o changes to struct led_classdev.
Select LEDS_RGB to enable building drivers using the RGB extension.
Flag LED_SET_HUE_SAT allows to specify that hue / saturation should be overridden even if the provided values are zero.
Some examples for writing values to /sys/class/leds/<xx>/brightness:
(now also hex notation can be used)
Quoted 6 lines
255 -> set full brightness and keep existing color if set
0 -> switch LED off but keep existing color so that it can be restored
if the LED is switched on again later
0x1000000 -> switch LED off and set also hue and saturation to 0 0x00ffff -> set full brightness, full saturation and set hue to 0 (red)
Umm, that's rather strange interface -- and three values in single sysfs file is actually forbidden.
Plus, it is very much unlike existing interfaces for RGB LEDs, which we already have supported in the tree. (At least nokia N900 and Sony motion controller already contain supported three-color LEDs).
Now... yes, there's work to be done for the 3-color LEDs. Currently, they are treated as three different LEDs. (Which makes some sense, you can use "battery charging" trigger for LED, and CPU activity trigger for green, for example). It would be good to have some kind of grouping, so that userspace can tell "these 3 leds are actually combined into one light".
Hi!
Quoted 15 lines
Quoted 6 lines
At first thanks for the review comments.
Treating the three physical LEDs of a RGB LED as separate LED devices might have been implemented due to the lack of alternatives.
With one trigger controlling the red LED and another controlling the green LED we may end up with a yellow light. Not sure whether this is what we want.
Quoted 8 lines
One driver for this extension was the idea of triggers using color to visualize states etc.
Therefore it's not only about userspace controlling the color. As a trigger is bound to a led_classdev we need a led_classdev representing a RGB LED device.
And ok: If required the sysfs interface can be splitted into separate attributes for hue, saturation, and (existing) brightness.
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0

Quoted 7 lines

/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.

This involves the same issue you were opposed to: three values per sysfs attribute.

Quoted 20 lines

Then we could have normal "trigger" mechanism, working with the color used. Probably recognizing "none" for manual control, and "pattern" for pattern control. (Pattern would be controlled as described above).
Quoted 9 lines
It's hard to address these requirements by having the settings in separate attributes, due to synchronization issues, and LED trigger mechanism specificity.
There is a question whether we can bend the sysfs "one value per sysfs file" rule down to RGB LEDs needs.
Of course other brilliant ideas on how to approach the problem are more than expected.
linux-api sounds like interesting idea, please cc me if you do that.
Best regards,
Pavel

Signature · 2 lines

Best regards,
Jacek Anaszewski

Pavel Machek

2016-04-01 21:18 UTC #14 lore raw

Hi!

Quoted 23 lines

Quoted 23 lines
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"

Quoted 6 lines

Quoted 3 lines
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.
This involves the same issue you were opposed to: three values per sysfs attribute.

And solves a lot of other things. Like actually being backwards compatible.

And yes, it involves three values in a file, but now it is array of led brightnesses, and that might actually be acceptable. (At least the values have uniform meaning).

Plus, it is not "issue you were opposed to" it is "something that is not permitted by sysfs maintainers".

Thanks,
Pavel

Signature · 6 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jacek Anaszewski

2016-04-04 21:34 UTC #15 lore raw

Hi Pavel,

Quoted 28 lines · Pavel Machek

Hi!
Quoted 26 lines
Quoted 26 lines
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.

Could you give an example on how to set a color for RGB LED using this interface? Would it be compatible with LED triggers? Where the "pattern" class would be implemented?

Quoted 12 lines

Quoted 2 lines
This involves the same issue you were opposed to: three values per sysfs attribute.
And solves a lot of other things. Like actually being backwards compatible.
And yes, it involves three values in a file, but now it is array of led brightnesses, and that might actually be acceptable. (At least the values have uniform meaning).
Plus, it is not "issue you were opposed to" it is "something that is not permitted by sysfs maintainers".

Signature · 2 lines

Best regards,
Jacek Anaszewski

Pavel Machek

2016-04-05 09:01 UTC #16 lore raw

Hi!

Quoted 23 lines

Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"

Quoted 7 lines

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.
Could you give an example on how to set a color for RGB LED using this interface? Would it be compatible with LED triggers? Where the "pattern" class would be implemented?

Well, 'echo "50 60 70" > /sys/class/pattern/lp5533::0/color' should set the color for the led. 'echo "trigger-name" > trigger' would set the trigger, probably just toggling between LED off and set color for the old triggers.

Where to implement the patterns is different question, but for example drivers/leds/pattern?

Best regards,
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Jacek Anaszewski

2016-04-05 19:45 UTC #17 lore raw

Quoted 33 lines · Pavel Machek

Hi!
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.
Could you give an example on how to set a color for RGB LED using this interface? Would it be compatible with LED triggers? Where the "pattern" class would be implemented?

Quoted 7 lines

Well, 'echo "50 60 70" > /sys/class/pattern/lp5533::0/color' should set the color for the led. 'echo "trigger-name" > trigger' would set the trigger, probably just toggling between LED off and set color for the old triggers.
Where to implement the patterns is different question, but for example drivers/leds/pattern?

I'd rather leave the pattern issue for now, since it seems to be different from the problem Heiner was trying to solve with his LED RGB extension. Moreover, hardware patterns are device specific and it could be hard to propose a generic interface.
Drivers can always expose their custom sysfs attributes for configuring the patterns.

Regardless of the above, some of your considerations brought me an idea on how to add generic and backwards compatible support for setting RGB color at one go.

Currently LED class drivers of RGB LED controllers expose three LED class devices - one per R, G and B color component. I propose that such drivers set LED_DEV_CAP_RGB flag for each LED class device they register. LED core, seeing the flag, would create a generic "color" sysfs attribute for each of the three LED class devices.

The "color" attribute would contain "R G B" values. Setting the "color" attribute of any of the three LED class devices would affect brightness properties (i.e. constituent colors) of the remaining two ones. It would result in disabling any active triggers and writing all the three color settings to the RGB LED controller at one go.

We would probably need additional op in the LED core : color_set.

Having the color set to nonzero value would signify the the three LED class devices are in sync and that setting a trigger on any of them applies to the remaining two ones. It would have to be considered whether existing triggers could be made compatible with synchronized RGB LED class devices.

I'm curious what do you think about the idea.

Pavel, Heiner, others?

Signature · 6 lines

Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Heiner Kallweit

author

2016-04-05 20:43 UTC #18 lore raw

Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski:

Quoted 73 lines · Pavel Machek

Quoted 33 lines
Hi!
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.
Could you give an example on how to set a color for RGB LED using this interface? Would it be compatible with LED triggers? Where the "pattern" class would be implemented?
Quoted 7 lines
Well, 'echo "50 60 70" > /sys/class/pattern/lp5533::0/color' should set the color for the led. 'echo "trigger-name" > trigger' would set the trigger, probably just toggling between LED off and set color for the old triggers.
Where to implement the patterns is different question, but for example drivers/leds/pattern?
I'd rather leave the pattern issue for now, since it seems to be different from the problem Heiner was trying to solve with his LED RGB extension. Moreover, hardware patterns are device specific and it could be hard to propose a generic interface.
Drivers can always expose their custom sysfs attributes for configuring the patterns.
Regardless of the above, some of your considerations brought me an idea on how to add generic and backwards compatible support for setting RGB color at one go.
Currently LED class drivers of RGB LED controllers expose three LED class devices - one per R, G and B color component. I propose that such drivers set LED_DEV_CAP_RGB flag for each LED class device they register. LED core, seeing the flag, would create a generic "color" sysfs attribute for each of the three LED class devices.
The "color" attribute would contain "R G B" values. Setting the "color" attribute of any of the three LED class devices would affect brightness properties (i.e. constituent colors) of the remaining two ones. It would result in disabling any active triggers and writing all the three color settings to the RGB LED controller at one go.
We would probably need additional op in the LED core : color_set.
Having the color set to nonzero value would signify the the three LED class devices are in sync and that setting a trigger on any of them applies to the remaining two ones. It would have to be considered whether existing triggers could be made compatible with synchronized RGB LED class devices.

Quoted 4 lines

I'm curious what do you think about the idea.
Pavel, Heiner, others?

Exposing "coupled LED devices" as separate LED devices most likely is ok when accessed from user space as the name of the led_classdev's indicates that they belong together.
But how about a trigger wanting to set a RGB LED to a specific color? (That's not available yet but one possible use case for RGB LED's) A trigger is bound to a led_classdev currently. In addition we'd need to introduce some kind of super_led_classdev having links to the respective R/G/B led_classdev's (+ trigger functions dealing with this super_led_classdev).

These changes / extensions are not needed if a RGB LED is exposed as one led_classdev, just with flag LED_DEV_CAP_RGB set.
OK, we'd still have to change the sysfs interface as obviously setting hue/sat/brightness via one "brightness" attribute is not acceptable. However this constraint might not affect the kernel-internal trigger API (usage of parameter brightness in led_trigger_event).

I see Pavel's point that there might be different types of multi-color LED's. At least we have:
- multi-color LED's where each single LED is visible even if all are switched on
- multi-color LED's like RGB LED's where you usually just see a uniform color

Last but not least regarding the patterns:
Something like proposed by Pavel is e.g. (partially) supported by the blink(1) firmware. That would be an example of such a "hardware-accelerated" pattern.

As I see it the current blinking support then would be one special case of a pattern. As a consequence once having pattern support we might be able to switch users of blinking to pattern and remove the blinking support.

Regards, Heiner

Jacek Anaszewski

2016-04-05 22:15 UTC #19 lore raw

Hi Heiner,

Thanks for the feedback.

Quoted 76 lines · Heiner Kallweit

Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski:
Quoted 75 lines · Pavel Machek
Quoted 33 lines
Hi!
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 23 lines
Quoted 7 lines
It would have the same downsides as in case of having r, g and b in separate attributes, i.e. - problems with setting LED colour in a consistent way. This way LED blinking in whatever colour couldn't be supported reliably. It was one of your primary rationale standing behind this design, if I remember correctly. Second - what about triggers? We've had a long discussion about it and this design turned out to be most fitting.
Are on/off triggers really that useful for a LED that can produce 16 million colors?
I believe we should support patterns for RGB LEDs. Something like [ (time, r, g, b), ... ] . Ok, what about this one?
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.
Could you give an example on how to set a color for RGB LED using this interface? Would it be compatible with LED triggers? Where the "pattern" class would be implemented?
Quoted 7 lines
Well, 'echo "50 60 70" > /sys/class/pattern/lp5533::0/color' should set the color for the led. 'echo "trigger-name" > trigger' would set the trigger, probably just toggling between LED off and set color for the old triggers.
Where to implement the patterns is different question, but for example drivers/leds/pattern?
I'd rather leave the pattern issue for now, since it seems to be different from the problem Heiner was trying to solve with his LED RGB extension. Moreover, hardware patterns are device specific and it could be hard to propose a generic interface.
Drivers can always expose their custom sysfs attributes for configuring the patterns.
Regardless of the above, some of your considerations brought me an idea on how to add generic and backwards compatible support for setting RGB color at one go.
Currently LED class drivers of RGB LED controllers expose three LED class devices - one per R, G and B color component. I propose that such drivers set LED_DEV_CAP_RGB flag for each LED class device they register. LED core, seeing the flag, would create a generic "color" sysfs attribute for each of the three LED class devices.
The "color" attribute would contain "R G B" values. Setting the "color" attribute of any of the three LED class devices would affect brightness properties (i.e. constituent colors) of the remaining two ones. It would result in disabling any active triggers and writing all the three color settings to the RGB LED controller at one go.
We would probably need additional op in the LED core : color_set.
Having the color set to nonzero value would signify the the three LED class devices are in sync and that setting a trigger on any of them applies to the remaining two ones. It would have to be considered whether existing triggers could be made compatible with synchronized RGB LED class devices.
I'm curious what do you think about the idea.

Quoted 7 lines

Quoted 2 lines
Pavel, Heiner, others?
Exposing "coupled LED devices" as separate LED devices most likely is ok when accessed from user space as the name of the led_classdev's indicates that they belong together.
But how about a trigger wanting to set a RGB LED to a specific color?

RGB triggers would use a new color_set op. It means that currently implemented triggers would be unable to set arbitrary color, but they could be used only in a monochrome context.

Quoted 11 lines

(That's not available yet but one possible use case for RGB LED's) A trigger is bound to a led_classdev currently. In addition we'd need to introduce some kind of super_led_classdev having links to the respective R/G/B led_classdev's (+ trigger functions dealing with this super_led_classdev).
These changes / extensions are not needed if a RGB LED is exposed as one led_classdev, just with flag LED_DEV_CAP_RGB set.
OK, we'd still have to change the sysfs interface as obviously setting hue/sat/brightness via one "brightness" attribute is not acceptable. However this constraint might not affect the kernel-internal trigger API (usage of parameter brightness in led_trigger_event).

We would still have to abuse brightness parameter semantics.

Quoted 4 lines

I see Pavel's point that there might be different types of multi-color LED's. At least we have:
- multi-color LED's where each single LED is visible even if all are switched on
- multi-color LED's like RGB LED's where you usually just see a uniform color

I think that if we are talking about RGB LEDs it is always the second case.

Quoted 7 lines

Last but not least regarding the patterns:
Something like proposed by Pavel is e.g. (partially) supported by the blink(1) firmware. That would be an example of such a "hardware-accelerated" pattern.
As I see it the current blinking support then would be one special case of a pattern. As a consequence once having pattern support we might be able to switch users of blinking to pattern and remove the blinking support.

Let's split patterns related discussion into a separate thread. It would be best if it began with a patch.

Signature · 6 lines

Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Pavel Machek

2016-04-06 08:52 UTC #22 lore raw

Hi!

Quoted 22 lines

Quoted 22 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Lets say we have
/sys/class/pattern/lp5533::0
/sys/class/pattern/software::0
/sys/class/led/n900::red ; default trigger "lp5533::0:0" /sys/class/led/n900::green ; default trigger "lp5533::0:1" /sys/class/led/n900::blue ; default trigger "lp5533::0:2"
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Normally, pattern would correspond to one RGB LED. We could have attribute "/sys/class/pattern/lp5533::0/color" containing R,G,B for this pattern.
Could you give an example on how to set a color for RGB LED using this interface? Would it be compatible with LED triggers? Where the "pattern" class would be implemented?
Well, 'echo "50 60 70" > /sys/class/pattern/lp5533::0/color' should set the color for the led. 'echo "trigger-name" > trigger' would set the trigger, probably just toggling between LED off and set color for the old triggers.

Quoted 7 lines

Quoted 2 lines
Where to implement the patterns is different question, but for example drivers/leds/pattern?
I'd rather leave the pattern issue for now, since it seems to be different from the problem Heiner was trying to solve with his LED RGB extension. Moreover, hardware patterns are device specific and it could be hard to propose a generic interface.

Well, RGB leds are basically useless without pattern support. And I believe we can do generic interface.

Quoted 13 lines

Drivers can always expose their custom sysfs attributes for configuring the patterns.
Regardless of the above, some of your considerations brought me an idea on how to add generic and backwards compatible support for setting RGB color at one go.
Currently LED class drivers of RGB LED controllers expose three LED class devices - one per R, G and B color component. I propose that such drivers set LED_DEV_CAP_RGB flag for each LED class device they register. LED core, seeing the flag, would create a generic "color" sysfs attribute for each of the three LED class devices.

Quoted 5 lines

The "color" attribute would contain "R G B" values. Setting the "color" attribute of any of the three LED class devices would affect brightness properties (i.e. constituent colors) of the remaining two ones. It would result in disabling any active triggers and writing all the three color settings to the RGB LED controller at one go.

Having one attribute across three devices is rather ugly. And we'll need to solve the pattern issue one day.

What's tricky about patterns is that you need to control 3 (or more) leds at a time. Problem you are trying to solve here is ... control of 3 leds, at the same time.

So let's solve them together.
Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2016-04-06 09:12 UTC #21 lore raw

Hi!

Quoted 21 lines

Quoted 8 lines
We would probably need additional op in the LED core : color_set.
Having the color set to nonzero value would signify the the three LED class devices are in sync and that setting a trigger on any of them applies to the remaining two ones. It would have to be considered whether existing triggers could be made compatible with synchronized RGB LED class devices.
Quoted 4 lines
I'm curious what do you think about the idea.
Pavel, Heiner, others?
Exposing "coupled LED devices" as separate LED devices most likely is ok when accessed from user space as the name of the led_classdev's indicates that they belong together.
But how about a trigger wanting to set a RGB LED to a specific color? (That's not available yet but one possible use case for RGB LED's) A trigger is bound to a led_classdev currently. In addition we'd need to introduce some kind of super_led_classdev having links to the respective R/G/B led_classdev's (+ trigger functions dealing with this super_led_classdev).

Quoted 6 lines

These changes / extensions are not needed if a RGB LED is exposed as one led_classdev, just with flag LED_DEV_CAP_RGB set.
OK, we'd still have to change the sysfs interface as obviously setting hue/sat/brightness via one "brightness" attribute is not acceptable. However this constraint might not affect the kernel-internal trigger API (usage of parameter brightness in led_trigger_event).

Your proposal would break existing hardware. We already have RGB LEDs exposed as three LEDs. It is too late to change interface there.

Quoted 5 lines

I see Pavel's point that there might be different types of multi-color LED's. At least we have:
- multi-color LED's where each single LED is visible even if all are switched on
- multi-color LED's like RGB LED's where you usually just see a uniform color

Well, I suggest we ignore that distinction. Yes, I can see different colors coming from different directions, but the LED was clearly designed to look like single light.

Quoted 7 lines

Last but not least regarding the patterns:
Something like proposed by Pavel is e.g. (partially) supported by the blink(1) firmware. That would be an example of such a "hardware-accelerated" pattern.
As I see it the current blinking support then would be one special case of a pattern. As a consequence once having pattern support we might be able to switch users of blinking to pattern and remove the blinking support.

No, you can't remove existing blinking support, due to backwards compatibility reasons.

Pavel

Signature · 2 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Pavel Machek

2016-04-06 09:16 UTC #20 lore raw

Hi!

Quoted 6 lines

Quoted 3 lines
As I see it the current blinking support then would be one special case of a pattern. As a consequence once having pattern support we might be able to switch users of blinking to pattern and remove the blinking support.
Let's split patterns related discussion into a separate thread. It would be best if it began with a patch.

Lets design userland interface first, then decide how to implement it in the kernel. Patches are useless at this point.

And actually... without patterns, existing interface works just fine. Even if you can't "atomically" write values to three different files, operation is so fast that user will not see the intermediate state, anyway. So solving the "atomic" issue without solving the rest is pretty much useless.

Best regards,
Pavel

Signature · 6 lines

(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Jacek Anaszewski

2016-04-06 09:54 UTC #23 lore raw