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

[Yves-Alexis Perez]

On Tue, Dec 04, 2007 at 02:55:34PM +0000, Henrique de Moraes Holschuh wrote:
> 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.

Yes, 20071203 :)
> 
> 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.

Currently this works fine, I'll see with brightness.
> 
> > 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.

I've configured USuspendRamAcpiSleep 3 in /etc/hibernate/ususpendram.conf and
the backlight is properly restored on resume.
> 
> 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.

Well, if I don't manage brightness change myself, nobody cares to do it. And
the delay is only after a first sleep/resume.
> 
> 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 :-(

Mhmh ok. I'll try to report a bug against xserver-xorg-video-intel. If
KEY_BRIGHTNESSUP/DOWN are correctly reported, do you confirm that the correct
behavior _is_ for intel driver to manage the backlight itself?
> 
> > 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.

Well I guess it tries to only adjust backlight for acpi_video0.
But there, I'm confused. Who should adjust brightness? gnome-power-manager (or
other client) trough hal, or intel driver?

Cheers,
-- 
Yves-Alexis