Hi,
On 28-03-19 22:09, Pavel Machek wrote:
Hi!
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 ?
Create "glow-while-charging-on-when-full" trigger? :-).
More concretely... I'd create one system that makes sense (glow (*)
while charging, on when full), and implement that. It looks like the
code already is in ./drivers/power/supply/power_supply_leds.c .
This indeed seems to give most of the infra, but the whole trigger
mechanism currently only allows setting-up blinking through triggers,
not glowing. I'm tempted to just use the blink interface to implement
glowing on this hardware, since that is what we really want (blinking
is to distracting for the user IMHO). What is your take on just
implementing glowing through the standard blink interface ?
Optionally we could add a custom sysfs attr to the driver to
switch between the blink interface between actually blinking and
glowing and default to glowing.
Regards,
Hans
