Hi! Reason #1: > >>Hmm. So userland can read the LED state, and it can get _some_ value > >>back, but it can not know if it is current state or not. > Why a dedicated file? Are we going to mirror brightness here > wrt r/w (show/store) behavior ? If not userspace now needs > 2 open fds which is not really nice. If we are and we are > not going to use poll for something else on brightness itself > then why not just poll directly on brightness ? Reason #1 is above. Reason #2 is "if userspace sees brightness file, it can not know if the notifications on change actually work or not". Reason #3 is that you broke Tony's system. Polling does not make sense when trigger such as "CPU in use" is active. Reason #4 is that there are really two brightnesses: 1) maximum brightness trigger is going to use 2) current brightness Currently writing to "brightness" file changes 1), but reading returns 2) when available. So, feel free to propose better interface. One that solves #1..#4 above. 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
