[Intel-gfx] [RFC] [intel-gfx] :The backlight issue when KMS is used

[Matthew Garrett]

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 
device registers.

I'm not sure what you mean by arbiter order?

-- 
Matthew Garrett | mjg59 at srcf.ucam.org