Hi! > >>>>As pointed in other email, we do not know if HW really controls keyboard backlight, > >>>>so adding "fake" trigger on machines without HW control is not a good idea. > >>> > >>>Well, if we know that hardware will not change the brightness on its > >>>own, yes, I'd avoid the trigger. If we don't know (as is common on > >>>ACPI machines, I'd keep the trigger). > >> > >>I'd drop the trigger approach due to the mess it can make in peoples' > >>minds due to the fact that LED class device handles trigger events > >>generated by itself. > > > >We can teach people. IMO the LED that changes itself is special, and > >trigger explains that nicely to the userspace. Plus, it allows us to > >keep this functionality out of the core. > > Please refer to the downsides of this appraoch: > > - lack of information if given LED class device supports hw > generated POLLPRI events Userspace can plainly see that a trigger is active, and knows to expect > - impossible to apply other trigger while polling That's a good thing. We _don't_ want polling to be active when trigger such as "CPU active" is active. We want userspace to monitor hardware events but not software ones. > >>I'd add a file hw_brightness_change or async_brightness or something > >>similar and make it only readable/pollable. current_brightness is > >>ambiguous and questionable. > > > >Well, exact name is not too important... > > The name should clearly explain the file purpose. I bet that we would > see many questions once the file appeared in the mainline. > Also, I'm afraid that I wouldn't be able to explain this name in > few simple words, without daunting the listener, or even triggering > the discussion on brightness shortcomings we've already gone through. Well, feel free to suggest non-confusing name. Unfortunately, yes, we'll need to do some explaining, as existing "brightness" behaviour is already pretty tricky / confusing / counterintuitive. Lets at least make sure new additions are clean and simple. Thanks, 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
