Hi! > >Also, how would we read the > >brightness set by the firmware? We'd have to read brightness > >file, so still two files would have to be opened which is > >a second drawback of this approach. > > No, look carefully at the definition of the read behavior > I plan to put in the ABI doc: > > "Reading this file will return the actual led brightness > when not blinking and no triggers are active; reading this > file will return the brightness used when the led is on > when blinking or triggers are active." That's not sane semantics. Userspace would have to read three files (racy) to find out about triggers etc. It also prevents modelling "hardware-changes-brightness-behind-kernel's-back" as a trigger. > So for e.g. the backlit keyboard case reading this single > file will return the actual brightness of the backlight, > since this does not involve blinking or triggers. Stop obsessing about "ingle file". FDs are pretty cheap. This is sysfs. > >Having no difference in this area between the two approaches > >I'm still in favour of the read-only file for notifying > >brightness changes procured by hardware. > > That brings back the needing 2 fds problem; and does Actually you have turned "2 fds" into "3 fds", as userspace now needs to check for trigger _and_ blinking _and_ actuall brightness. fds are cheap, but that is still not nice design. 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
