HI,
On 28-03-19 11:36, Pavel Machek wrote:
Hi!
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.
Why not? Normal triggers can have parameters, these new hw_* triggers
can have parameters, too, with same semantics.
But... yes, it will mean some work if you really need to support all
the functionality, and I do think that it should be ok to just support
a limited subset. (probably hw_on_when_charging" and
"hw_glows_when_charging" with fixed parameters).
Well we will also need a normal "glows_when_charging" and "on_when_charging"
because on at least one model hardware, the hw trigger does not work and
we need a software trigger to do "on/glow when charging"
Thinking more about it, I think that for this specific case, we could
probably drop the hardware control at all since the hw cannot differentiate
between charging and full. Then we could do glow while-charging and
on when full (and AC power present).
Yes I think that that would actually be best (glow while charging, on when full
done in sw) but how would we model this ?
Regards,
Hans
