On 6/10/19 7:22 PM, Oleh Kravchenko wrote:
10.06.19 20:01, Jacek Anaszewski пише:
On 6/9/19 10:23 PM, Oleh Kravchenko wrote:
09.06.19 22:31, Jacek Anaszewski пише:
I just want to clerify - for now LEDs board has 2 from 3 LEDs with effect function.
1. Screen frame led is just blinking, so blink_set() is fit well to this.
2. Pipe led actually consist from 3 leds and when effect is enabled next pattern is used:
^
|
LED1 > OFF ON ON ON
|
LED2 > OFF OFF ON ON
|
LED3 > OFF OFF OFF ON
|
+----^----^----^----^----> time
Pattern trigger applies to a single LED so it won't fit for this
pattern.
Currently we don't support patterns spanning on multiple LEDs,
so you would have to come up with your own solution.
What I can recommend is a trigger that would be created by your driver
and would activate this sequence.
How to be sure this trigger can be applied only to Pipe LED?
After thinking a bit more of it I came to the conclusion that instead
of a trigger the driver should create its own specific sysfs files for controlling the effect.
Some time ago we had a proposal of generic support for hardware triggers
that this one could make use of, but the idea didn't seem to introduce
much gain in comparison to the driver specific files.
So, you could have "effect_on" file which would accept "true" or "false"
(other API name proposals are welcome), that would be created by
every LED class device created by the driver.
The effect will be activated when all three LEDs have the effect_on
file value set to "true".
Sorry, I think we don't understand each other ;)
OK, so below depicting clarifies the things a bit, but
it doesn't change too much regarding the API.
,-----------. -\
| | \
| | \
| SCREEN | \
| | +---- **Screen Frame LED Tube**
| | / only one LED with ID 'S' or 0x53
| | /
| | / It can blinks when brightness set to '2' or 0x32
`-----------' -/
So this LED will use blink_set op for activating hw blinking.
-
PIPE_LED1 * \ **Pipe LEDs**
PIPE_LED2 * +---- 3 leds with ID 'P' or 0x50
PIPE_LED3 * / we can't control every LED individually.
- When brightness 0x32, this LEDs start playing 'leaking' effect:
This LED will need dedicated file for controlling the effect.
Blinking feature cannot be used for that because it will not
behave uniformly with software blink fallback.
^
|
LED1 > OFF ON ON ON
|
LED2 > OFF OFF ON ON
|
LED3 > OFF OFF OFF ON
|
+----^----^----^----^----> time
-
,-----------. \
| Place for | \
| coffee | +---- **Vending Area LED**
| cap | / Simple OFF/ON behavior
`-----------' /
-
This one will support neither blink_set nor effect file.
So you will be fine?
if I proceed with recommendation from Dan to have sysfs attribute which actually set brightness to '2' (0x32) value?
I don't think there is necessity for anything like
el15203000-blink. Just use what LED framework is used to
support. Activate hw blinking when specific blink delay_on/off
intervals are given.
--
Best regards,
Jacek Anaszewski
