Each oem uses a different method for backlight control.  It may be controlled by the asic or it may be controlled by a controller on the motherboard or some special gpio setup.  The only reliable method is to use the backlight controls provided via acpi.

(In reply to comment #1)
> Each oem uses a different method for backlight control.  It may be controlled
> by the asic or it may be controlled by a controller on the motherboard or some
> special gpio setup.  The only reliable method is to use the backlight controls
> provided via acpi.

Does that mean that hal will be always needed ? or we can use acpi directly with gnome-power-manager ?

(In reply to comment #2)
> Does that mean that hal will be always needed ? or we can use acpi directly
> with gnome-power-manager ?

I shouldn't say acpi as not all platforms support it.  What I mean is the kernel backlight interface which on most x86 systems goes through acpi.  If gpm uses that, it will work with all systems that support it rather than doing one-offs for every system or requiring all drivers to implement an xrandr property.

> --- Comment #3 from Alex Deucher <agd5f@yahoo.com> 2010-04-27 13:46:12 PDT ---
> I shouldn't say acpi as not all platforms support it.  What I mean is the
> kernel backlight interface which on most x86 systems goes through acpi.  If gpm
> uses that, it will work with all systems that support it rather than doing
> one-offs for every system or requiring all drivers to implement an xrandr
> property.
> 
gpm can't really use that directly, it doesn't run as root (and may not
even be on the same machine as the display).  it makes more sense to
have the driver use the sysfs interface and provide access to it through
randr imo (intel does that, in any case)...

What do we do on systems with drivers that don't support randr 1.2?  Pretty much all systems with a backlight control use the kernel backlight interface.

(In reply to comment #5)
> What do we do on systems with drivers that don't support randr 1.2?  Pretty
> much all systems with a backlight control use the kernel backlight interface.

So, if i did understand that well, this is definitely a won't fix in radeon ?

Alex, BACKLIGHT is being implemented by intel and nouveau, with the logic that the DRM is the best place for poking into the graphics hardware. Whilst I agree that vendor-specific ACPI methods will work with _most_ hardware, I'm sure that implementing BACKLIGHT and hooking it into the DRM will be very little code, and ensure that the DRM and ACPI work together, rather than trampling on each others state.

IMHO the best approach is to implement the 'Backlight' (it's spelled this way) property in the driver, which in turn uses ACPI if available.

intel and radeonhd do it that way, I assume nouveau as well.

Note that 'BACKLIGHT' is obsolete since RandR 1.3 specs. At least the gnome tools and xbacklight have been updated accordingly.

You're trading one set of pain for another.  Why go through the extra effort of adding all this stuff to the driver?  We already have a kernel backlight interface that works on just about all hardware with a backlight.  It works on pdas, cellphones, non-xrandr-1.2-capable drivers, weird non-x86 platforms, etc.

As I said before, not all oems use the GPU backlight control.  Some oems use other things (external controllers, gpios, etc.).  So we either add code to pass it all through to acpi on x86, or we add a bunch of logic to the driver to try and handle the cases we can handle directly and pass what we can't to apci.  Then we have to add additional logic to disable the acpi stuff in the case of the driver doing the control itself, otherwise both interfaces will try and do it.  In the majority of cases, the acpi stuff works as expected.  Also, what about non-X use cases?  How do we change the backlight in that case?  The kernel backlight interface would be the obvious choice; why create a second one for X that has to be duplicated in all the drivers?

It just seems like a lot of work and a lot more potential bugs just to get us to a place on par with were we are today.

(In reply to comment #9)
> Also, what
> about non-X use cases?  How do we change the backlight in that case?  The
> kernel backlight interface would be the obvious choice; why create a second one
> for X that has to be duplicated in all the drivers?

Well, this is not about a second mechanic controlling the same thing, it's just about a common higher-level interface on top of whatever is in charge of actual controlling the hardware. That it's using the low-level sysfs stuff on Linux is just an implementation detail that the higher-level randr interface should not export to desktop-like stuff at all.

The X/non-X logic is actually the other way around, it's: if X controls the screen, it should also control the backlight belonging to the screen. And non-X custom use cases are obviously not touched at all by an interface provided by X. :)

And the actual driver in X could be shared between all drivers if that is your concern. It could even be extended to support more than sysfs if needed, and all that logic would live well behind randr and not need to leak into any other crufty userspace logic.

That all seems pretty simple and consistent to me. :)

(In reply to comment #10)
> 
> Well, this is not about a second mechanic controlling the same thing, it's just
> about a common higher-level interface on top of whatever is in charge of actual
> controlling the hardware. That it's using the low-level sysfs stuff on Linux is
> just an implementation detail that the higher-level randr interface should not
> export to desktop-like stuff at all.
> 
> The X/non-X logic is actually the other way around, it's: if X controls the
> screen, it should also control the backlight belonging to the screen. And non-X
> custom use cases are obviously not touched at all by an interface provided by
> X. :)
> 

It is irrelevant whether the backlight change comes through some xrandr wrapper that uses the backlight interface or the backlight interface directly.  It just adds indirection.

> And the actual driver in X could be shared between all drivers if that is your
> concern. It could even be extended to support more than sysfs if needed, and
> all that logic would live well behind randr and not need to leak into any other
> crufty userspace logic.

If someone wants to add some common X interface for exposing backlight control, fine by me, but it seems like a lot of pointless work.

All this does is add a layer of indirection just because.

We have:
1. gpm uses backlight interface directly:
   gpm -> kernel backlight interface
2. gpm uses xrandr:
   gpm -> xrandr -> xserver -> ddx -> drm -> kernel backlight interface

Not only is there a lot more indirection, it also involves having to code all that stuff in between.  Plus, no one has yet addressed how we deal with non-xrandr-1.2 capable drivers.  What do you do on a laptop with a savage or some old nv chip?  Or some pda or tablet that uses some fbdev hack?  How does gpm deal with that?  Who's going to go and add xrandr-1.2 support to all these old drivers?  I guess in those cases we can add a special hack to gpm.

> 
> That all seems pretty simple and consistent to me. :)

What does this gain us?  Seems to me, it's just a lot of work in lots of places just so we can use another interface that does the same thing that an existing common interface already does.

Maybe we should add an xrandr interface to adjust the sound card volume.  If X is running, why not use xrandr to adjust the volume?  I know there's a standard way to access the sound card, but X is running and it should have it's own way.

(In reply to comment #11)
> What does this gain us?  Seems to me, it's just a lot of work in lots of places
> just so we can use another interface that does the same thing that an existing
> common interface already does.

It's better this way because the RandR case has to be supported by the tools anyway. Because there are drivers for which there is no kernel backlight driver. One example is intel legacy - it's still exposed by the intel xorg driver.

> Maybe we should add an xrandr interface to adjust the sound card volume.  If X
> is running, why not use xrandr to adjust the volume?  I know there's a standard
> way to access the sound card, but X is running and it should have it's own way.

You remember there *were* standardization processes running to get audio over X working. They were all broken by design, though, as far as I remember, but many people would still love to see this happen. Unlikely any time soon (or later), though.

(In reply to comment #12)
> 
> It's better this way because the RandR case has to be supported by the tools
> anyway. Because there are drivers for which there is no kernel backlight
> driver. One example is intel legacy - it's still exposed by the intel xorg
> driver.

Wouldn't it be easier to fix at one driver to use the backlight interface than to fix everything else (radeon, fbdev, cirrus, savage, vesa, etc.) to use xrandr?

> 
> > Maybe we should add an xrandr interface to adjust the sound card volume.  If X
> > is running, why not use xrandr to adjust the volume?  I know there's a standard
> > way to access the sound card, but X is running and it should have it's own way.
> 
> You remember there *were* standardization processes running to get audio over X
> working. They were all broken by design, though, as far as I remember, but many
> people would still love to see this happen. Unlikely any time soon (or later),
> though.

I know.  I was kidding :) Seriously though, I though we were trying to get X out of being in the OS business.