Bug 12567

Created attachment 11751 [details]
xorg.log after boot with lid closed, external display is ok

Created attachment 11752 [details]
xorg.log after lid opened, the start of this is the same as the first attachmenr

Created attachment 11753 [details]
output of xrandr --verbose, unchanged before and after opening the lid

If you don't have any apci modules loaded then I suspect the bios is banging on the HW directly when it gets a lid event.  Since these are thinkpads, I'd suggest loading the thinkpad acpi modules and setting the event mask to produce only events rather than calling the bios methods.  Obviously something is trashing the state and it's not the driver (it doesn't get any acpi events), so it's probably the bios.

(In reply to comment #4)
> If you don't have any apci modules loaded then I suspect the bios is
> banging on the HW directly when it gets a lid event.  Since these are 
> thinkpads, I'd suggest loading the thinkpad acpi modules and setting
> the event mask to  produce only events rather than calling the bios
> methods.  Obviously something is trashing the state and it's not the
> driver (it doesn't get any acpi events), so it's probably the bios.

This was my first thought too and I checked this and it doesnt work.

I thought it is a driver problem because the driver gets "something"
which leads to a new output probe (see the attached log files, the
second is taken directly after opening the lid and the driver was
triggered by "something").

I have not yet understood how output changes are recognized by the
server but something triggers this (without changing the xrandr-visible
configuration, the output of xrandr did not change after opening the lid.

Sorry for asking - is there any hope for this? I checked again with
the latest RC and the problem is still there.

Thanks and greetings

Ulrich

I'll see if I can get some time this week to try and reproduce it.

Thanks! I am more than willing to support you. Please give a hint
when we should add more information.

I was able to reproduce this and it was the bios that was mucking with the HW.  By toggling the right bios scratch reg bits, I was able to prevent the bios from mucking with the hardware while the driver is active.  I've also added lid status detection support (with some limitations).
commits:
1b231d28fdda5cdc44bb9d2075d4edfd8f17e21f
7afd04c1e4ffa6e4e5ba08ae90ba002237dc282b

These git changes break backlight controll support on Thinkpad Z60m. 

When X is active you are not able to change backlight level via Fn+Home/Fn+End. Also thinpad_acpi based backlight controll no longer works.

Not touching bit 3 (counting from 0) in bios_4_scratch makes brightness setting possible again but brightness level is saved and restored by X (so after making manual changes via Fn+Home/End and switching from X to console and then back - X sets again old saved level while it should not mess with level at all). Level is afaik keept in 0-3 bits in bios_5_scratch - these also shouldn't be touched.

My problem is now fixed on master:
http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commitdiff;h=6f080d00e6f4f84d5e0d6b4eff302bf42c230e81

There is also related problem with restoring backlight on vt-switch. I'm appending description of the problem here for reference but well - that should go into new bugreport. 

From irc:
"<arekm>: you are in X, you set backlight to some level; let say level 7. You vt-switch to console, change backlight level to 1; switch back to X - backlight level is set to some higher value (like 6 or 7; didn't check exactly which) instead of still being at level 1 as set on console. Now you press Fn+Home to increace backlight level and ... it actually goes to level 2. So at least one Fn+Home/End press is needed to get "correct" level after going back to X. Something similar was when you switched to console, set level 1; killed X and started it again - it didn't keep level 1 but something different. Didn't dig into this too deeply."