Hi Pavel,
On 04/15/2016 01:53 PM, Pavel Machek wrote:
Hi!
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
Hi!
> >>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_e
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 hav
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 d
On 04/07/2016 10:45 PM, Pavel Machek wrote:
Hi!
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
Hi!
> >>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
>
On 04/06/2016 10:52 AM, Pavel Machek wrote:
Hi!
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:
Hi!
> >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 separ
Hi!
> > 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
> >
Hi!
> >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
Hi Heiner,
Thanks for the feedback.
On 04/05/2016 10:43 PM, Heiner Kallweit wrote:
Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski:
On 04/05/2016 11:01 AM, Pavel Machek wrote:
Hi!
It would have the same downsides as in case of having r, g and b in
separate attributes, i.e. - problems with s
Am 05.04.2016 um 21:45 schrieb Jacek Anaszewski:
> On 04/05/2016 11:01 AM, Pavel Machek wrote:
>> Hi!
>>
>>> 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 blinkin
On 04/05/2016 11:01 AM, Pavel Machek wrote:
Hi!
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 prima
Hi!
> 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
>
Hi Pavel,
On 04/01/2016 11:18 PM, Pavel Machek wrote:
Hi!
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
Hi!
> >>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
> >>behin
On 04/01/2016 03:57 PM, Pavel Machek wrote:
Hi!
On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote:
Hi Heiner and Pavel,
On 03/29/2016 10:38 PM, Heiner Kallweit wrote:
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
Hi!
First, please Cc me on RGB color support.
Add generic support for RGB C
Hi!
> >>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
Hi!
> >>>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
On 04/01/2016 04:07 PM, Pavel Machek wrote:
Hi!
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
Hi!
On Wed 2016-03-30 09:57:38, Jacek Anaszewski wrote:
> Hi Heiner and Pavel,
>
> On 03/29/2016 10:38 PM, Heiner Kallweit wrote:
> >Am 29.03.2016 um 12:02 schrieb Pavel Machek:
> >>Hi!
> >>
> >>First, please Cc me on RGB color support.
> >>
> >>>Add generic support for RGB Color LED's.
> >>>
> >>
On 04/01/2016 02:55 PM, Pavel Machek wrote:
Hi!
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
Hi!
> > 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
Hi!
> >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
Hi!
> > 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 individu
Hi Heiner,
On 03/30/2016 03:59 PM, Heiner Kallweit wrote:
On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek wrote:
Hi!
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 gr
On Wed, Mar 30, 2016 at 3:03 PM, Pavel Machek wrote:
> Hi!
>
>> >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
Hi!
> >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)
On 03/29/2016 11:43 PM, Pavel Machek wrote:
Hi!
First, please Cc me on RGB color support.
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_
Hi Heiner and Pavel,
On 03/29/2016 10:38 PM, Heiner Kallweit wrote:
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
Hi!
First, please Cc me on RGB color support.
Add generic support for RGB Color LED's.
Basic idea is to use enum led_brightness also for the hue and saturation
color components.T
Am 29.03.2016 um 23:43 schrieb Pavel Machek:
> Hi!
>
>>> First, please Cc me on RGB color support.
>>>
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
Hi!
> > 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 requi
Hi!
> > First, please Cc me on RGB color support.
> >
> >> 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.
> >>
>
Am 29.03.2016 um 12:02 schrieb Pavel Machek:
> Hi!
>
> First, please Cc me on RGB color support.
>
>> 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
>> cha
Hi!
First, please Cc me on RGB color support.
> 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 enab
Hi Heiner,
Thanks for the updated version. Some nitpicking below.
Please remove "Color" from the patch title.
On 03/01/2016 10:26 PM, Heiner Kallweit wrote:
Add generic support for RGB Color LED's.
^^^
Ditto.
Basic idea is to use enum led_brightness also for
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
37 matches
Mail list logo
