Re: [PATCH 2/2] video: mark "actual_brightness" deprecated

[Richard Purdie <rpurdie@rpsys.net>]

On Wed, 2008-12-31 at 10:12 +0800, Zhang Rui wrote:
> On Tue, 2008-12-30 at 18:37 +0800, Richard Purdie wrote:
> > On Wed, 2008-12-24 at 11:07 +0800, Zhang Rui wrote:
> > > /sys/class/backlight/.../brightness returns a cached value,
> > > which confuses a lot of users.
> > > 
> > > Make the "brightness" reflect the actual backlight levels,
> > > and mark /sys/class/backlight/.../brightness as depreacated
> > > in this patch.
> > 
> > This isn't an acceptable approach I'm afraid. We have some hardware
> > which needs limiting of the backlight brightness in cases of low battery
> we use "brightness" as the backlight limiting? then how does it work?

Limiting is done by the driver itself so userspace would request "5",
the hardware would only allow "2" due to power contraints so
"birghtness" reads "5" but actual_brightness reads "2".

> users can always set it to a higher or lower value no matter whether
> it's low battery or not. IMO we'd better to use another file instead.
> I got a couple of bugs about "the brightness file doesn't work", because
> if people can change the backlight by poking "brightness", they prefer
> to get the current brightness by reading it. what do you think?

No, this can't work. If you put a value into a sysfs file you should get
the same value back. This is why "actual_brightness" exists and is
readonly, reflecting the end result. Were possible/necessary that is
read from the hardware. People expecting anything else from the
interface aren't using it as designed.

> > for example. "brightness" is the user requested value,
> > "actual_brightness" is the one that is actually active.
> why do we need the "user requested value"?
> does some application depend on it?

Two reasons, one is that some applications might want to see both what
was set and also what the result was. Secondly, I'm uneasy with a sysfs
file that write one value and reads something different. The current
setup doesn't cause any problems as long as people understand what to
expect and why? By merging the two things it gets more confusing and
also removes information which is potentially useful to userspace.

Cheers,

Richard