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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
