On Sat, 2007-03-03 at 16:06 +0000, James Simmons wrote: > > > Richard, is this actually a bug, or is it a config error or something > > > like that? > > > > > > And should we track it as a post-2.6.20 regression? > > > > Its a regression IMO. Arguably its a Kconfig error but a nasty one as > > the defaults cause the problems. Different people seem to have different > > interpretations but to me it appears that the patch from James causes > > backlights to fail to turn on for a variety of devices which worked > > before. > > It is NOT a Kconfig error. The problem is that for many fbdev drivers > the backlight code is broken. For some magic reason it only works on > pmacs. Most likely because the firmware properly sets up the backlight. > Plus we have the conflict with acpi backlight. > Think about it. Enabling the backlight code breaks the backlight. > Without the backlight driver the default behaviour of the backlight works. > Who sets up the default behavior? I don't have a LCD panel with a > backlight othewise I would track the problem down.
I not arguing several fb driver's backlight code isn't broken, it is. We have a Kconfig problem though since we used to stop users selecting things that didn't work and now we're allowing them. Worse still, the defaults break for people. That is a regression. Anyhow, the patch I proposed should let people enable/disable it at runtime with defaults known to work which should address the problem until someone figures out how to fix the backlight drivers themselves properly. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
