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]
Date:	Thu, 22 Feb 2007 01:07:38 +0000 (GMT)
From:	James Simmons <jsimmons@...radead.org>
To:	Richard Purdie <rpurdie@...ys.net>
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 Wed, 2007-02-21 at 00:56 -0500, Yaroslav Halchenko wrote:
> > I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
> > Iv'e tried, but, once again, I experienced the same issue with 19-mm?
> > kernels.
> > 
> > I built 2.6.20-mm2 without backlight support
> > $> grep BACKLIGH /boot/config-2.6.20-mm2 
> > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> > # CONFIG_FB_BACKLIGHT is not set
> > # CONFIG_FB_RIVA_BACKLIGHT is not set
> > # CONFIG_FB_RADEON_BACKLIGHT is not set
> > 
> > that "eliminated" the problem. Also I can see the screen with pure
> > 2.6.20 with backlight support (whatever it does since after
> > loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
> > 
> > *$> grep BACKLIGH /boot/config-2.6.20 
> > # CONFIG_FB_BACKLIGHT is not set
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > CONFIG_BACKLIGHT_DEVICE=y
> > 
> > 
> > > Also, do you normally see files under /sys/class/lcd?
> > nope... after I load lcd module, no files under :-/ regardless either it
> > is mm or not. But there are files under /sys/class/backlight/ for mm2
> > compiled with backlight support (whenever the screen is dark as per my
> > original email)
> 
> There should be no files appearing under /sys/class/lcd, so thats all
> normal. There is another report with similar symptoms which also sounds
> like enabling the following options are at fault:

Correct. LCD class was never used by anyone.
 
> # 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.
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ