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. 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. 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. Best regards, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Attachment:
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
