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

[Zhang Rui <rui.zhang@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

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.

thanks,
rui

[-- Attachment #2: backlight-manager --]
[-- Type: application/mbox, Size: 3195 bytes --]