Re: PM regression with LED changes in next-20161109

[Pavel Machek <pavel@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]