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

yakui_zhao yakui.zhao at intel.com
Wed Apr 8 02:56:19 CEST 2009


On Tue, 2009-04-07 at 15:38 +0800, Matthew Garrett wrote:
> On Tue, Apr 07, 2009 at 03:25:23PM +0800, yakui_zhao wrote:
> > On Tue, 2009-04-07 at 13:57 +0800, Matthew Garrett wrote:
> > > No, since in UMS mode the X server handles the backlight registers.
> > If so, there is no change about the backlight flowchart in UMS mode.
> > 
> > And only when the KMS mode is used, a new backlight I/F is registered.
> > Right?
> 
> Right.
> 
> > > 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.
> > Yes. We will have to create the communication channel between backlight
> > device and i915 driver. And when a backlight I/F is registered, we will
> > have to check whether the backlight I/F in 915 should be unregistered. 
> > Right? 
> > Does this make the problem complex? 
> 
> Not really. It's not a lot of code.
When a new backlight I/F is registered, it should unregister the
backlight I/F registered in 915 driver if it exists. And before i915
driver registers a backlight I/F, it will have to check whether the
backlight I/F is already registered by other code. If it exists, it will
give up.
And this code seems hack. 

If so, we will have to do so even for the boxes based on non-intel
platforms. 
> 
> > > I'm not sure what you mean by arbiter order?
> > What I said is which backlight I/F should be selected if there exist
> > multiple backlight I/F?
> 
> The platform-specific one.
> 




More information about the Intel-gfx mailing list