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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1172137565.5837.24.camel@localhost.localdomain>
Date:	Thu, 22 Feb 2007 09:46:05 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	James Simmons <jsimmons@...radead.org>
Cc:	Yaroslav Halchenko <lists@...russian.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: no backlight on radeon after recent kernel "upgrade"s

On Thu, 2007-02-22 at 01:07 +0000, James Simmons wrote:
> > # CONFIG_FB_RIVA_BACKLIGHT is not set
> > # CONFIG_FB_RADEON_BACKLIGHT is not set
> > 
> > I suspect these options only work on certain hardware and aren't
> > generic. James, any idea what hardware these do/don't work with?
> > 
> > Worst case, we set them to depend on PMAC_BACKLIGHT again I guess...
> 
>    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. 

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?

Cheers,

Richard

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/