Hi! > > > If I understood correctly we need to handle two things: > > > > > > 1) Provide poll() for userspace when LED level is changed (either > > > by HW > > > > > > or other user call) > > > > > > 2) Deal with fact that on _some_ hardware, special key is hardwired > > > to > > > > > > change LED level > > > > > > So why for 1) we cannot use existing sysfs file "brightness"? I do > > > not see any problem with it. > > > > That was our first attempt at this, but because the brightness may > > also be changed by triggers / blink-timers, we need to wakeup poll() > > in those cases too (anything else would be inconsistent) and doing > > such a wakeup in that case has turned out to cause too much overhead > > in some cases (even if userspace is not listening), specifically the > > idle power uses on some systems got multiplied by a factor of 5 or > > more. > > > > So this approach was rejected. > > But approach with exporting new sysfs file with name current_brightness > with existence of old brightness sysfs file is not good and in my > opinion it is even worst as current situation (= without poll > support). It is neccessary, see the current discussion. > What happen in next 5 years? Somebody point that sysfs file "brightness" current_brightness will only appear on machines and in situations, where we, well, can report current brightness. When you read "brightness" file, you don't know if you are getting current brightness or not, and it can't be changed easily. Please go through the discussion. This design was chosen for a reason. 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
