On Wed, 2010-04-28 at 11:51 +0200, Kay Sievers wrote: > On Wed, Apr 28, 2010 at 11:38, Richard Hughes <hughsi...@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 _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
