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

From: Richard Purdie
Date: Wed Feb 21 2007 - 20:11:09 EST

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?


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



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at