[Intel-gfx] [RFC] [intel-gfx] :The backlight issue when KMS is used
mjg59 at srcf.ucam.org
Mon Apr 6 22:57:17 PDT 2009
On Tue, Apr 07, 2009 at 11:45:11AM +0800, yakui_zhao wrote:
> On Sat, 2009-04-04 at 00:29 +0800, Matthew Garrett wrote:
> > Right. I'd imagine it as i915 loading and calling is_acpi_backlight().
> > If that returns false, it should register a backlight device and also a
> > notifier. If a machine-specific platform device (like thinkpad_acpi or
> > dell_laptop or whatever) then loads, i915 should unregister its driver
> > and leave it up to the machine-specific one. The DDX would then use the
> > backlight device under all circumstances.
> A good idea. When there is no generic ACPI backlight I/F(_BQC/_BCL/_BCM)
> or platform backlight I/F, a new baclight I/F(using platform I2C
> command) will be registered in i915 driver.
> Will this new backlight I/F be registered in both UMS/KMS mode?
No, since in UMS mode the X server handles the backlight registers.
> But if we do so, it seems that we have to solve the dependency issue
> among acpi_video, i915 and platform driver.
> For example: I915 driver is loaded firstly and the interface will be
> registered. But after the acpi video driver/platform driver is loaded,
> how to send the notification event that i915 should unregister its
> interface? If the interface is unregistered, we will have to consider
> the arbiter order.
The acpi case is uninteresting - acpi_video_backlight_support() doesn't
require the acpi video driver. The platform driver case is more
interesting, but the easiest solution is probably to add a notifier
chain for backlight device add and have i915 unregister when a platform
I'm not sure what you mean by arbiter order?
Matthew Garrett | mjg59 at srcf.ucam.org
More information about the Intel-gfx