[Intel-gfx] [RFC] [intel-gfx] :The backlight issue when KMS is used
yakui.zhao at intel.com
Wed Apr 8 02:59:55 CEST 2009
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
> 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?
More information about the Intel-gfx