quoted

   Ug. Previously it did the selecting for you. If you selected 
backlight support the fbdev backlight would just come to life. This caused 
problems for the case of having ACPI backlight and a fbdev driver with 
backlight support. Two drivers controling the same hardware is not the
greatest idea. I made it so that people explictly had to pick the backlight
with a fbdev device. The other reason for this change was not every 
one is using a LCD display. I have a system at home that uses a CRT. 
   Plus their is the case of "standard" PC graphics cards being used 
in embedded devices. In this case even tho the graphics card has backlight 
support the external lcd/backlight is routed through gpio independent of 
the embedded graphics card. In such case we don't want to enable the
backlight for the graphics card but enable it.
    In a nut shell the solution is select the backlight support for your
fbdev driver if you need it.

This is ugly for distribution maintainers as pick the wrong Kconfig
options and your device breaks. You need a different build depending on
the hardware you have. 

Distros would have to enable "standard" backlights to maximize their 
target machines. In other words they will aim for backlights from the ACPI layer 
for x86_64/ia32 machine and pmac_backlights for select ppc machines.
Specially since most default kernels on distros use only vgacon for intel 
type machines.

I understand some people need to be able to turn these things on but it
sounds like the majority of users don't need it and it will break things
for them. The config option sounds tempting to them though...

In case anyone else is wondering, the commit in question is
http://git.o-hand.com/?p=linux-rpurdie-backlight;a=commitdiff;h=e0e34ef7f02915cfe50e501e9f32c24217177a96
and previously, all the appropriate entries had "depends PMAC_BACKLIGHT"

I think the way forward is going to be to have the backlights disabled
by default at runtime and require enabling through a framebuffer module
parameter. The should be enabled by default in the PMAC_BACKLIGHT case.
Anyone needing it can then pass the appropriate parameter. Does that
sound like the best solution?

That is the correct solution. Basically people that select PMAC_BACKLIGHT
expect there driver to automatically to work. Basically they want 
PMAC_BACKLIGHT to work as a generic selectfor there card. I will work up a 
patch.