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

[yakui_zhao]

On Tue, 2009-04-07 at 16:48 +0800, Zhang, Rui wrote:
> CC Thomas, Len and linux-acpi mail list.
> 
> On Tue, 2009-04-07 at 16:22 +0800, Matthew Garrett wrote:
> > On Tue, Apr 07, 2009 at 04:20:34PM +0800, Zhang Rui wrote:
> > 
> > > All subsystems can register a set of callbacks for backlight control in
> > > its own way, e.g. ACPI, platform driver, i915.
> > > And the backlight manager only exports one single I/F to users, like:
> > > ----|
> > >     |----brightness
> > >     |----actual_brightness
> > >     |----max_brightness
> > >     |----...
> > >     |----mode
> > > and it supports multiple modes, e.g.
> > > 1. generic ---ACPI
> > > 2. platform---platform drivers
> > > 3. legacy-----i915
> > 
> > This seems to be a lot of complexity for an uncommon case. Is there any 
> > real need to modify the mode at runtime?
> 
> if this is implemented, the video_detect.c can be removed because we
> don't need to detect the ACPI video extension when loading platform
> drivers.
> every driver that has its own ways to control the backlight can register
> a set of callbacks and then it's the backlight manager's responsibility
> to choose which one to use.
> 
> >  What happens if the platform 
> > driver gets loaded before i915?
> > 
> the backlight manager always choose the one with the highest priority if
> multiple callbacks are registered. i.e
> if (ACPI control methods are available)
> 	changes to the "generic" mode
> else if (platform specific callbacks are available)
> 	changes to the "platform" mode
> else if (i915 callbacks are available)
> 	changes to the "legacy" mode
> 
> the backlight manager always run this logic when a new set of callbacks
> is registered/unregistered.
Is this manager realized in kernel space or user space?
> 
> thanks,
> rui