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]

Date:	Thu, 22 Feb 2007 01:10:16 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Alex Romosan <romosan@...orax.lbl.gov>,
	Yaroslav Halchenko <kernel@...russian.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org,
	linux-fbdev-devel@...ts.sourceforge.net,
	James Simmons <jsimmons@...radead.org>
Subject: Re: no backlight on radeon after recent kernel "upgrade"s

On Wed, 2007-02-21 at 22:51 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Feb 2007, Richard Purdie wrote:
> > I have a thinkpad with Intel GM graphics ;-). I need it to work so I try
> > not to experiment too much on it. I've just tried the ibm-acpi driver
> > and it doesn't work well :-(.
> 
> 2.6.21-rc, or 2.6.20? 

2.6.21-rc1

> If it is in 2.6.21, could you give me a report of how
> it fares on 2.6.20?

Maybe next week. I'm away over the weekend and I need it working now ;-).

> > * 'echo 0 > brightness' lowered the intensity but by a level or two, not
> > set it to level 0. A couple of more attempts and it did jump from 7 -> 1
> > and so on, it seems erratic.
> 
> I know it used to work fine before 2.6.20.  Let me check...  works fine on a
> T43, 2.6.20 (Radeon X300).  I need more data to fix it :-)

The following sequence is reproducible:

echo 7 > brightness (repeat until actual_brightness reads 7)
echo 0 > brightness (brightness reads 0, actual_brightness reads 4)
echo 0 > brightness (brightness reads 0, actual_brightness reads 0)

I suspect this is interference from software on the machine as it does
show an onscreen display when I change the values in sysfs and the
values on the OSD don't match what's really going on.  The
actual_brightness does match the screen.

I guess this just means we need to get userspace to agree on one method
of access for this kind of thing. It makes me wondering where the
hardware brightness keys fit into things though...

> > actual_brightness always seems to be correct, as does brightness so it
> > looks like its not updating the hardware correctly.
> 
> Well, if you have the ACPI video module loaded, unload it.  Does it work
> now?

No change if unloaded.

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/