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

[Jesse Barnes]

On Fri, 03 Apr 2009 13:49:38 +0800
yakui_zhao <yakui.zhao at intel.com> wrote:
>     How about following what we have done in UMS mode ?
>     a. When there exists the ACPI backlight I/F, the ACPI I/F will be
> hook up in drmmode_display.c and exposed to xrandr tool. Then the
> backlight can be changed by xrandr tool(the ACPI I/F is called). Of
> course the backlight can also be changed by ACPI I/F.  It is similar
> with what we have done in UMS mode. Of course to eliminate the
> potential inconsistency, the other three backlight control modes
> won't be exposed again.   
>     
>     b. If there is no ACPI backlight I/F, the native kernel backlight
> property will be exposed. And then the backlight can be changed by
> xrandr. (No ACPI I/F can control the brightness).

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.

Thoughts?
-- 
Jesse Barnes, Intel Open Source Technology Center