On Wed, 2008-12-31 at 13:41 +0000, Matthew Garrett wrote:
> Richard, how about something like this? If the hardware changes the
> state of the backlight behind us, the current code may make it
> impossible to set it back to the previous state without resynchronising
> the value first. Is there any currently supported hardware where this
> would be a sufficiently expensive or disruptive operation to warrant the
> check?
I'll accept that argument. It is an expensive operation on some hardware
but that path already has sysfs writes etc. so it doesn't really matter.
If it really bothers some hardware they can make the check in the driver
I guess.
I'll be sorting out the backlight tree in the next day or so and will
queue something like this for merging.
Cheers,
Richard
> diff --git a/drivers/video/backlight/backlight.c b/drivers/video/backlight/backlight.c
> index fab0bc8..064b428 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -134,10 +134,8 @@ static ssize_t backlight_store_brightness(struct device *dev,
> else {
> pr_debug("backlight: set brightness to %d\n",
> brightness);
> - if (bd->props.brightness != brightness) {
> - bd->props.brightness = brightness;
> - backlight_update_status(bd);
> - }
> + bd->props.brightness = brightness;
> + backlight_update_status(bd);
> rc = count;
> }
> }
>
--
Richard Purdie
Intel Open Source Technology Centre
--
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
