(Unfortunately another scenario with lid open/close which does not work, this time an R52) We have some TP R52 with Radeon X300 (M22) PCIE and the following scenario does not work: When booted with lid closed, the external display works ok (both DVI and VGA). When opening the lid after X is started, the external display goes blank and the internal display remains blank. _Sometimes_ it is possible to make both displays work again with according xrandr commands, in most cases only a reboot helps. Maybe this is somehow related to the similar bug for R51 but the screen-off of the external display is new here. We have no ACPI-methods active so this results solely from the driver. We are using git from yesterday.
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."
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.