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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
