[Q] Software control of LCD backlight?

[Alex Deucher]

On 8/11/07, René Rebe <rene at exactcode.de> wrote:
> Hi,
>
> On Saturday 11 August 2007 17:11:21 Alex Deucher wrote:
> > On 8/10/07, Hal V. Engel <hvengel at astound.net> wrote:
> > > On Friday 10 August 2007 14:31, Xavier Bestel wrote:
> > > > Le vendredi 10 août 2007 à 15:30 -0400, Alex Deucher a écrit :
> > > > > I don't know anything much about the ddc/ci spec, but it would be
> > > > > pretty easy to expose the i2c interface for each output in randr.
> > > > > What's we'd do wtih that interface depends on what's needed for
> > > > > ddc/ci.
> > > >
> > > > Then ddccontrol has lots of interesting code, and a pretty monitor
> > > > database in xml format (all monitors inheriting from the VESA settings),
> > > > but once again this code is GPL.
> > > >
> > > >       Xav
> > >
> > > At one time the main ddccontrol developers were looking for a way to
> > > incorporate thier code base into a larger project.  They contacted the
> > > lm-sensors project about this.  Other than lm-sensors also using the i2c
> > > interface it was not a good fit and the lm-sensors project was not
> > > interested.     On the other hand the functionality in the ddccontrol library
> > > is a good fit for X.Org and I am perplexed that they didn't make a similar
> > > proposal to X.Org at that time.   There are only 6 developers on the project
> > > and so it seems to me that it might be possible to convice them to relicense
> > > the library code (the project has a library, a command line front end and a
> > > GTK front end) to something that works for X.Org as a prelude to migrating
> > > the library functionality to be a standard X.Org library.  Just a thought.
> > >
> > > On the other hand looking at the code base it looks like most of the code in
> > > the library is there to deal with i2c interfacing so it may not be too big of
> > > a deal to just start from scratch if the randr folks intend to expose the i2c
> > > interface anyway.
> >
> > On the xorg side, we could just release a lib the exposes the xserver
> > i2c interface.  the randr could just expose i2c bus pointers from the
> > outputs.  any app that wanted access to the i2c buses could use the
> > lib to do stuff (dump edid, do ddc/ci, etc.).  if we ever add a GPU
> > level randr, we could also expose non-output related i2c buses for
> > multi-media and whatnot.
>
> Probably in the long-term the USB connected and controlable monitors
> (Apple Cinema Displays and others) should also be mapped to the
> individual screens.
>
> There is a tiny program to control them available:
>
>   http://t2-project.org/packages/acdctl.html
>
> But I think in the long run (desktop usability wise) xrandr should know
> about them so that it doesn't make a different how to control laptop and
> external displays via xrandr.

Unless we want to expose the full list of ddc/ci monitor controls via
randr, randr  would just be providing the i2c interface.  the control
would all be done trough a lib and some other app like ddccontrol or
whatever. that lib could then have a back end for the randr interface
and the usb one.

Alex