Re: no backlight on radeon after recent kernel "upgrade"s

[James Simmons <jsimmons@infradead.org>]

> >    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.