[Bug 27859] Please support the BACKLIGHT property in radeon

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=27859

--- Comment #11 from Alex Deucher <agd5f at yahoo.com> 2010-04-29 08:52:30 PDT ---
(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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.