On Fri, 3 Apr 2009 17:29:06 +0100 Matthew Garrett <mj...@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 ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
