Hi,
On 31-03-19 20:53, Pavel Machek wrote:
On Thu 2019-03-28 23:47:08, Hans de Goede wrote:
Hi,
On 28-03-19 23:43, Marek Behun wrote:
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.
Isn't glowing doable via led patterns?
A (software) trigger cannot select / set a led pattern, so either we
need a whole separate glowing API which seems overkill, or we need
to use the existing blink API. I guess one option would be to give
the led_trigger_blink function a "glow_if_possible" bool extra
parameter and pass this along to the actual led-driver.
Call it pattern API and it will be useful for more than glowing :-).
True, but the pattern API is very generic, where as glowing is pretty
specific, having triggers request glowing sounds like something which
I can see more triggers do; as for random patterns not so much.
More specifically we will often want to use hw glowing when available,
but not use a software pattern for this because that will cause too
much wakeups.
Regards,
Hans
