[ltp] thinkpad-acpi release 0.18-20071203 uploaded to ibm-acpi.sf.net

[Henrique de Moraes Holschuh]

On Tue, 04 Dec 2007, Yves-Alexis Perez wrote:
> What is precisely "*very* up-to-date"? I'm currently running 2.6.24-rc4 witch
> thinkpad-acpi 0.18-20071013. video.c is loaded and thinkpad-acpi runs without

I assume you mean 20071203?  If not, please update.

That is very up-to-date... but unfortunately, 2.6.24-rc still has some
_potential_ problems with ACPI, and it could causes trouble on the *61.

You can try applying whatever is in the "acpi-release" branch of Len Brown's
acpi tree, if it was not merged into 2.6.24-rc4 yet.

> argument. When I first boot, everything seems to work fine. If I put the t61
> to sleep, then resume, I can see two things:
> 
>   - the backlight is off (i boot using acpi_sleep=s3bios and put to sleep with
> 	hibernate-ram -f). I can switch to vt1 then back to vt7 and now the
> 	backlight is on.

It is always a good idea to try s3_bios,s3_mode on thinkpads, since their
BIOS does support it and it **usually** fixes many potential problems.

Note that it might change with the very latest versions of X.org, as it is
now learning to mess with the backlight properly *and* it messes with the
BIOS scratch registers too, which could potentially cause some weirdness.
It is the danger of being in the bleeding edge :-)

>   - the brightness up and brightness down keys have some delay (wich they
> 	don't have just after the boot). I catch the events in acpid and use
> 	xbacklight to set the brightness, but I can see that it's the acpi event
> 	wich have a delay.

You should not need to do *anything* of the sort.  video.c should change the
brightness *by itself*.  If things try to handle backlight changes twice, it
causes borkages like the one you describe.

Now, if video.c is NOT changing brightness, it is because either it is
buggy, or because x.org messed with the BIOS scratch registers, and the BIOS
is honouring that and not changing the brightness.  Unless X.org and video.c
are communicating and video.c knows it is not to try to change brightness,
weird things might happen.  Ask the X.org people about it, I don't know
enough about this :-(

> Except this, it works fine, but I didn't find that much changes since the
> latest release (2.6.23-rc3 and thinkpad-acpi 0.18-20071112), except that the
> keys are correctly mapped in thinkpad-acpi.

Heh.  Good.

> As a side note, is there a way to tell video.c, or hal, or gnome-power-manager
> (or another tool to manage sleep and backlight) that it should use
> /sys/class/backlight/acpi_video1 and not acpi_video0?

I don't know.  But there is a patch flying somewhere (probably Len Brown's
acpi-test) that will cause any phantom video devices (ones that are not
active, but still present in the ACPI tables) to go away.

One can still have more than one *proper* and *functioning* backlight
device, though.  HAL and gnome should be able to deal with it, the same way
they should be able to deal with multiple audio cards and mixers in ALSA,
etc.  If they don't, you should file bugs about it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh