[Intel-gfx] [RFC] [intel-gfx] :The backlight issue when KMS is used
jbarnes at virtuousgeek.org
Fri Apr 3 18:24:08 CEST 2009
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
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.
Jesse Barnes, Intel Open Source Technology Center
More information about the Intel-gfx