[Intel-gfx] [RFC] [intel-gfx] :The backlight issue when KMS is used

[Jesse Barnes]

On Fri, 3 Apr 2009 17:29:06 +0100
Matthew Garrett <mjg59 at srcf.ucam.org> wrote:

> On Fri, Apr 03, 2009 at 09:24:08AM -0700, Jesse Barnes wrote:
> > I'd rather not have a native kernel backlight property (i.e. a
> > property on the LVDS output) exposed at all.  I chatted with
> > Matthew about this a little, and I think the best thing to do would
> > be to have the i915 driver register a backlight interface of its
> > own if one doesn't already exist (e.g. in the case of a platform
> > specific i2c interface and no ACPI backlight support).
> > 
> > We might have to hack the backlight class code a little to prevent
> > multiple registrations for the same device, but that shouldn't be
> > too hard.
> > 
> > Then whichever driver loads first (i915 or acpi video) would create
> > a backlight interface if it could, and the userspace driver could
> > use it; no need for new properties.
> 
> Right. I'd imagine it as i915 loading and calling
> is_acpi_backlight(). If that returns false, it should register a
> backlight device and also a notifier. If a machine-specific platform
> device (like thinkpad_acpi or dell_laptop or whatever) then loads,
> i915 should unregister its driver and leave it up to the
> machine-specific one. The DDX would then use the backlight device
> under all circumstances.

Yeah, that's the main thing.  I don't want to repeat the horror show of
the UMS backlight interface.  Everything should go
through /sys/class/backlight, and the kernel should figure out which
one is best (i.e. provides the most consistent experience).

-- 
Jesse Barnes, Intel Open Source Technology Center