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

Greg KH greg at kroah.com
Mon Aug 17 18:11:26 CEST 2009


On Sun, Aug 16, 2009 at 11:21:16PM +0100, 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.

How do I do this?

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

As stated before, Samsung said this was the best way to control the
backlight on these laptops, so should I ignore them?  :)

thanks,

greg k-h



More information about the Intel-gfx mailing list