[Intel-gfx] Legacy backlight control with KMS and BACKLIGHT property

[ykzhao]

On Mon, 2009-08-17 at 06:21 +0800, Matthew Garrett wrote:
> On Sun, Aug 16, 2009 at 03:10:03PM -0700, Greg KH wrote:
> > On Sun, Aug 16, 2009 at 02:26:22PM +0100, Matthew Garrett wrote:
> > > This seems basically right, but I don't think DMI's the correct 
> > > approach. We should be trying the registers on any device that doesn't 
> > > implement the ACPI code and doesn't provide a more generic 
> > > platform-specific interface.
> > 
> > How do we know this?  I'll gladly change the driver if there is some
> > other better way.  Right now I'm only adding laptops that we know need
> > this kind of configuration as there is no ACPI interface for the
> > control.
> 
> The probability of the backlight control registers being hooked up is 
> massively greater than the probability of it being done entirely in some 
> out of band manner, and even then you'll just have register writes that 
> do nothing. As Jesse says, the proper solution includes supporting the 
> hardware with off-chip backlight controllers - but I don't think docs on 
> how those are handled have been released by Intel.
> 
> What you probably do want to be doing is checking the mmio backlight 
> register and seeing whether the chip's in legacy, native or combination 
> mode. The opregion code already does this, so that probably wants to be 
> factored out and another entry point added for systems without any other 
> control method. DMI-strings and hardcoded PCI config writes will work, 
> but it's not really the correct solution.
This is what we have done in UMS code. It will firstly check whether
there exists the acpi backlight interface under
the /sys/class/backlight/. If it exists, it will use the acpi backlight
method to adjust the brightness. If it doesn't exist, it will read the
mmio register and select the backlight control method.(legacy, native,
combination). And the backlight control method is also switched by using
xrandr tool. (Opregion code is realized as the generic acpi control
method.)

In KMS mode the backlight property is not exposed to xrandr tool. In
such case the backlight can't be controlled by the xrandr tool. More
worse is that there is no interface that can control the backlight if
there is no acpi backlight interface under /sys/class/backlight/. 

In fact in KMS case if we expose a backlight property to xrandr in i915
driver, then the backlight can be controlled by the xrandr tool. But the
problem is which control method should be exposed to user-space.(acpi,
native, legacy, combo)


Another issue is the inconsistence between the different control
methods. In UMS case if we select the legacy control method by using
xrandr tool, we will get the incorrect brightness
through /sys/class/backlight/* when the backlight is adjusted through
xrandr tool. So we had better expose only one backlight interface under
the /sys/class/backlight/ and this interface is also hooked up by the
xrandr tool. In such case the driver will also register the backlight
interface under the /sys/class/backlight/.

But another problem arises. In kernel side three drivers can register
the backlight interface.
  >Acpi video (generic acpi method)
  >platform driver
  >i915 driver.
  Which should be selected? What rule should be followed to select the
backlight interface? 

Thanks.



> 
> > > Speaking of which, are we sure there isn't a Samsung-specific
> > > interface? Using a platform interface is always preferable to hitting
> > > the registers directly, since that way we don't have the firmware
> > > getting out of sync with the hardware.
> > 
> > From the rumors I have heard from some samsung contacts, they
> > recommended touching the pci config space directly, which implies that
> > there is no other way to do this right now :(
> 
> Fair enough.
>