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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
