[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