On 04/09/2016 06:01 PM, Pavel Machek wrote:
Hi!
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.
OK, now I've got your point. So we'd need to have a means for defining
patterns. The interface could be located at /sys/class/leds/patterns.
We'd need to have a flexible way for defining LED class devices involved
in a pattern. Since we cannot guarantee no space in a LED class device
name, then a single attribute containing space separated list is not an
option. We'd have to create a predefined set of attributes that would
contain LED class device name. Predefined implies that it would be
a fixed number, i.e. either some attributes would always remain unused
or, which is even worse, we could run out of free attributes for some
use cases.
There's a better solution: make pattern behave as a trigger for leds
it controls.
So we'd have
/sys/class/leds/patterns/lp5523
then we'd have
/sys/class/leds/lp5523::red/trigger = "lp5523:1"
/sys/class/leds/lp5523::green/trigger = "lp5523:2"
/sys/class/leds/lp5523::blue/trigger = "lp5523:3"
(or something similar, I'd have to boot the n900 to see the exact
names).
How about implementing patterns as a specific typer of triggers?
Let's say we have ledtrig-rgb-pattern:
Well, we'd need ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, ... , as we
can have more than one rgb led. But yes.
Triggers can have many listeners, i.e. led_trigger_event() sets
brightness on all LED class devices registered on given trigger.
We could have led_trigger_rgb_event() that would set brightness
on all groups-of-three LEDs registered on given rgb-trigger.
I agree that ledtrig-rgb-pattern-1, ledtrig-rgb-pattern-2, etc. would
be also needed to add a capability of setting different colors on
different LED devices.
After setting a trigger following sysfs attribute would appear
in a LED class device sysfs interface:
$cat /sys/class/lp5523::red/rgb_color
red green blue [none]
$echo "red" > /sys/class/leds/lp5523::red/rgb_color
and similarly
$echo "green" > /sys/class/leds/lp5523::green/rgb_color
$echo "blue" > /sys/class/leds/lp5523::blue/rgb_color
Yes, that would work -- selecting channels from the pattern.
Similar approach could be applied for blink patterns:
There could be additional attributes provided for defining
the position in a blink sequence, or/and blink period.
For patterns, I'd suggest array of (r g b time) values.
Pattern engines can do stuff like "slowly turn LED from off to red, then switch color to
white, then slowly turn it to yellow, then turn it off at once" with defined speeds
for "slowly" and option of either linear on non-linear brightness ramping.
The last option might be a bit too much, but I believe we should support the rest.
Yes, that's an interesting idea. It also turns out that trigger based
patterns could be also used for defining generic patterns for a group
of monochrome LEDs.
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
