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

[Jesse Barnes]

On Fri, 14 Aug 2009 11:13:28 -0700
Greg KH <greg at kroah.com> wrote:

> On Fri, Aug 14, 2009 at 10:56:39AM -0700, Jesse Barnes wrote:
> > On Fri, 14 Aug 2009 19:54:05 +0200
> > Matthias Hopf <mhopf at suse.de> wrote:
> > 
> > > Currently with KMS legacy backlight control isn't working at all.
> > > Also, the driver doesn't expose the BACKLIGHT RandR property in
> > > any case, so xbacklight doesn't work with KMS.
> > > 
> > > I've been working on a patch as a quick-hack for this (attached;
> > > please DON'T apply), and am finally understanding enough to
> > > actually implement this correctly together with GregKH.
> > > 
> > > 
> > > What we're supposing is
> > > 
> > > - a kernel driver for the /sys/class/backlight/ api for the legacy
> > > method
> > > - support in the driver to actually open this one (trivial)
> > > - support for the BACKLIGHT property in KMS case, *only* using the
> > >   kernel api method for now (will need some abstraction)
> > 
> > This sounds like the correct approach.  We have an RFE open on this
> > too: http://bugs.freedesktop.org/show_bug.cgi?id=20963
> 
> My question is, does this belong in the kernel side, to expose the
> backlight through /sys/class/backlight/, or do we do this on the
> userspace side in perhaps the xorg intel driver (where we can touch
> pci config space just as easily)?

We're trying to avoid any direct PCI access from userland these days.
I was hoping we could settle on the /sys/class/backlight interface.

> What does KMS expect to have happen?

KMS doesn't have a specific interface for this; apps like g-p-m
typically go through the server's xrandr interface or
access /sys/class/backlight directly.

-- 
Jesse Barnes, Intel Open Source Technology Center