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
signature.asc
Description: Digital signature
------------------------------------------------------------------------------
_______________________________________________ ibm-acpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
