Hi,
On 28-03-19 10:49, Pavel Machek wrote:
Hi!
Ok, so it seems we need "hardware_trigger" (or "hw_trigger"?) file,
anyway, because it is common for hardware to have few modes.
What about getting rid of hardware_controlled file, and just having
"hw_trigger", working similar to current "trigger" semantics?
hw_trigger would
* only be present if LED can be hardware controlled
* echo none > hw_trigger would give control to software
* echo mode > hw_trigger would give control to hardware, in given mode
* cat hw_trigger would list possible modes.
* echo 0 > brightness would clear set both "trigger" and "hw_trigger" to
none.
* any change to trigger or hw_trigger would set the other one to
"none".
But .. looking at proposal. I believe most consistent / logical
solution would be to simply add hardware triggers into list of
triggers, and treat them the same way. Yes, that would mean different
trigger lists per LED, but I don't think that's a problem, and it is
logical solution for our users.
OK, so we would have say a hw_battery_is_charging trigger for the PMIC
led driver we were discussing recently, and selecting this buts the
LED under hw control but this hw-trigger just turns the LED on and off.
The device also has a hw_pattern (on / blink / glow) which selects what
it shows when "triggered" (or manually turned on).
I assume this would then use a hw_pattern file, how do you see these
2 interacting ? What happens when the trigger is changed, does the
pattern then gets reset ? etc.
Actually, thinking about that again, in your case I'd just present
three triggers "hw_on_when_charging", "hw_blinks_when_charging" and
"hw_glows_when_charging"... if we really need to support all the
functionality.
But that does not allow selecting the frequency of blinking / glowing
and the hw can do the exact same thing in no-trigger / manual mode
and it would be preferable to have a single code path for setting
the pattern independent of turning the pattern on/off being under
manual or hw control.
Regards,
Hans
