Hi,
On 11/25/2016 03:49 PM, Pavel Machek wrote:
Hi!
Lets keep it simple. Yes, monitoring backlight state while hardware
updates it is useful. But doing the monitor when some kind of blinking
>from the kernel is active is just a unneccessary complexity...
Triggers are not limited to periodic blinking or reporting cpu
activity. There is also oneshot trigger that can be used e.g. when
user touches the screen, as Pali mentioned.
Using oneshot trigger for this would be pretty strange.
It was only an example to mention other than periodic triggers.
You could have a trigger that just turns the LED permanently on
after user touches the screen.
Notice that in
some cases (thinkpad battery led, for example) we either have firmware
controls the LED (but then software can't control it) or we have
software controlling the LED (but then we don't know what firmware
would put there). Maybe keyboard backlight can be controlled
"simultaneously" by both software and firmware, but there are
certainly LEDs that can't handle that, and IMO it would be nice to
have same interface.
Well.. actually... I think this is a little bit over complex and
probably unneccessary. I'd let Hans implement whatever he thinks is
easiest.
I'd say this is the trigger approach which is a bit convoluted.
In my eyes trigger approach is neccessary at least for some hardware,
and things it pretty clear: trigger on == LED changes without
userspace involvement. trigger off == userspace controls the LED.
It is likely that it would break many existing users.
So I'd do the trigger here. It is same way we can handle LEDs on
thinkpad. Yes, it means you won't be able to do oneshot trigger on
backlight. I don't think that's a huge problem.
There have been voices in this discussion claiming the opposite. :-)
--
Best regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
