On Tue, 07 Apr 2009 16:48:22 +0800 Zhang Rui <rui.zhang@xxxxxxxxx> 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. The other option of course (as discussed this morning on IRC w/Dr_Jackob) is to avoid using the sysfs backlight API in the KMS case (KMS clients would be expected to go through output properties instead). This has the disadvantage of essentially deprecating a currently used interface, but OTOH making for a more consistent interface across new output types with brightness control (DDC has bits for this, as does displayport I think). But we'd definitely want to preserve the current ACPI interaction, so we'd have to make the i915 and other DRM drivers clients of the ACPI or platform backlight drivers (at least internally to the kernel) where available. This might be a bit simpler than the de-registration stuff we talked about, and would intuitively extend to other output types that add backlight support in the future. Any thoughts about that? -- Jesse Barnes, Intel Open Source Technology Center -- 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
