Hi! > >> There might exist users that adjust LED brightness while having > >> active trigger. The best example is default-on trigger - it sets > >> brightness only on init, but remains active all the time. Whereas > >> this could be fixed, there is another case: think of changing blinking > >> brightness - it would be impossible. > > > > I don't see the breakage. For existing blinking and default-on > > triggers, existing behaviour would be kept. Difference would be that > > for hardware that changes triggers itself (like the keyboard light) we > > would present it as a trigger. And you are right -- there would be > > user visible changes there. You could not assign blinking, because > > .. it already has a trigger. But I believe it is reasonable. > > We've already received negative feedback regarding blocking > application of different trigger when hw brightness change > notifications Actually sometimes we'll get negative feedback for anything we do. I still believe exposing the backlight case as a trigger is a right thing. > are enabled. One solution to that is making the notifications > orthogonal to the trigger mechanism. The other possibility is to allow > for having more than one active trigger for a LED. > > We could think of defining a special type of persistent trigger that > would be always enabled. Yes, that could be done. I'd not call it persistent trigger, but with right name... #1: Apparently some LEDs change themselves, and we can't find how or when. That's thinkpad battery LED, for example. #2: Then there are some LEDs that change themselves, and we can get notifications. We should make it very clear that we'll not send notifications kernel did itself. So... for #1 and #2 something like led/hardware_changes_brightness and for #2 led/poll_for_hardware_brightness_change where poll() wakes the userspace up when the brightness changes, and read() can get new brightness...? 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
------------------------------------------------------------------------------ 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
