On Fri, 03 Apr 2009 13:49:38 +0800 yakui_zhao <yakui.z...@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 ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
