[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161111221224.GB10983@amd>
Date: Fri, 11 Nov 2016 23:12:24 +0100
From: Pavel Machek <pavel@....cz>
To: Hans de Goede <hdegoede@...hat.com>
Cc: Jacek Anaszewski <jacek.anaszewski@...il.com>,
Tony Lindgren <tony@...mide.com>,
Jacek Anaszewski <j.anaszewski@...sung.com>,
linux-leds@...r.kernel.org, linux-omap@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Darren Hart <dvhart@...radead.org>
Subject: Re: PM regression with LED changes in next-20161109
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
Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists