https://bugs.freedesktop.org/show_bug.cgi?id=27859
--- Comment #9 from Alex Deucher <[email protected]> 2010-04-28 09:20:47 PDT --- 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. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ xorg-driver-ati mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-driver-ati
