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:
backlight-manager
Description: application/mbox
