No BACKLIGHT for

Bastien Nocera hadess at hadess.net
Fri Apr 30 08:40:32 PDT 2010


On Wed, 2010-04-28 at 11:51 +0200, Kay Sievers wrote:
> On Wed, Apr 28, 2010 at 11:38, Richard Hughes <hughsient at gmail.com> wrote:
> > Sorry to open an old wound, but it looks like radeon won't be adding
> > BACKLIGHT into the driver, ever.
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=27859
> 
> That surely all belongs into the X server below the randr interface.
> The intel driver does use the kernel sysfs interface below the randr
> interface too. There is no reason other drivers can not simply do the
> same.

Which is broken if your system doesn't have a platform way of changing
the LCD backlight.

On my Macbook Air, I cannot change the backlight without switching to
UMS. In KMS, the intel driver tries to use the sysfs interface, and
there's none.

In UMS, the driver will go bit-banging itself, and can change the
backlight level that way.

> It should be reasonable simple to let X provide internally a generic
> sysfs backlight driver which can be wired up from individual drivers
> like radeon.
> 
> > Unless we can convince Alex otherwise, we'll need a trivial
> > ubacklight-type-daemon which is system activated for this hardware (or
> > a polkit helper root program).
> 
> In any case, I rather see to have these systems not be able to control
> their backlight with g-p-m, than to work around such rather simple
> issues that way. :) We need to put some pressure on the people who are
> in charge of solving these problems, and not try to work around them.
> That was HAL's strategy, which was wrong on so many levels, and which
> we absolutely need to avoid with the new stuff.

Agreed there. Either the driver or the platform should provide a way to
change the backlight. Random shell programs really isn't a viable
option.

Cheers



More information about the devkit-devel mailing list