[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130326152029.GA993@cantiga.alporthouse.com>
Date: Tue, 26 Mar 2013 15:20:29 +0000
From: Chris Wilson <chris@...is-wilson.co.uk>
To: Danny Baumann <dannybaumann@....de>,
David Airlie <airlied@...ux.ie>,
intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org
Subject: Re: [PATCH 1/1] drm/i915: Allow specifying a minimum brightness
level for sysfs control.
On Tue, Mar 26, 2013 at 04:13:13PM +0100, Daniel Vetter wrote:
> On Tue, Mar 26, 2013 at 12:48:45PM +0100, Danny Baumann wrote:
> > When controlling backlight devices via sysfs interface, user space
> > generally assumes the minimum level (0) still providing a brightness
> > that is usable by the user (probably due to the most commonly used
> > backlight device, acpi_videoX, behaving exactly like that). This doesn't
> > match the current behaviour of the intel_backlight control, though, as
> > the value 0 means 'backlight off'.
> >
> > In order to make intel_backlight consistent to other backlight devices,
> > introduce a module parameter that allows shifting the 0 level of the
> > intel_backlight device. It's expressed in percentages of the maximum
> > level. The default is 5, which provides a backlight level that is barely
> > readable. Setting it to 0 restores the old behaviour.
> >
> > Signed-off-by: Danny Baumann <dannybaumann@....de>
>
> Thus far our assumption always was that the acpi backlight works better
> than the intel native backlight. So everything only uses the intel
> backlight if there's no other backlight driver by default.
There are machines, such as the pnv netbook on my desk, on which
intel_backlight does nothing and the only control is through
acpi_backlight0. Generalising expected behaviour based on one firmware
implementation is fraught with danger.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists