Created attachment 40132 [details] [review] Xorg log I changed the panel in my Thinkpad T60 laptop as the old one was having backlight problems. With the new panel, X boots up fine but when I put the laptop in the docking station and attempt to use dual head, I lose the picture on the internal display. The output from xrandr suggests that X is assigning the same set of resolutions to both the internal display (14" 1024x768) and external display (17" 1280x1024 - connected via VGA). Looking in the Xorg.0.log file, it appears that the VGA and panel are using the same address for obtaining EDID information. I suspect that the panel is not returning any information and so defaults are being used (which works for the panel alone), but that when a second display is added, the EDID info for that display is being used for both. I will attempt this with the DVI port as I now have a docking station that exposes it.
Created attachment 40133 [details] [review] Output from dmesg
Created attachment 40134 [details] [review] xrandr output The xrandr output contains an additional modeline which I added manually as a copy of the autogenerated ones when the laptop was started without the external display. It doesn't produce an image either.
Additional notes: - radeon.new_pll=0 set in kernel options to prevent flickering of the external display. Bug reported against Fedora 12 (related to a kernel upgrade about a year ago).
Did this only start happening when you swapped in the new panel? Did it work before the panel swap? Some after market panels do not have the edid programmed correctly, or require edid reprogramming to work correctly. Anyway, in the short term, you should be able to get it working by forcing the the mode on the LVDS using xrandr. e.g., xrandr --output LVDS --mode 1024x768 --rate 60.0
(In reply to comment #3) > Additional notes: > > - radeon.new_pll=0 set in kernel options to prevent flickering of the external > display. Bug reported against Fedora 12 (related to a kernel upgrade about a > year ago). You are not using KMS according to your xorg log and dmesg output, so that option does nothing in this case.
(In reply to comment #4) > Did this only start happening when you swapped in the new panel? Did it work > before the panel swap? Some after market panels do not have the edid > programmed correctly, or require edid reprogramming to work correctly. Anyway, > in the short term, you should be able to get it working by forcing the the mode > on the LVDS using xrandr. e.g., xrandr --output LVDS --mode 1024x768 --rate > 60.0 Yes and yes. I've tried forcing the mode using that line, but I get the same result. Backlight on, but black screen. The only way I can get the internal panel to display anything is to disconnect the external monitor.
(In reply to comment #5) > (In reply to comment #3) > > Additional notes: > > > > - radeon.new_pll=0 set in kernel options to prevent flickering of the external > > display. Bug reported against Fedora 12 (related to a kernel upgrade about a > > year ago). > > You are not using KMS according to your xorg log and dmesg output, so that > option does nothing in this case. Strange. I thought I'd disabled KMS much earlier, but I can assert that it has a significant effect. Without it (when the old panel was working), booting into a recent Fedora 12 kernel would result in shake on the external display (lots at the edges, almost gone in the centre).
What are the pci ids subsystem ids for your card (lspci -vnn)? I can add a quirk for you to use locally, but I hesitate to push it upstream lest it break other users with the original panel.
(In reply to comment #8) > What are the pci ids subsystem ids for your card (lspci -vnn)? I can add a > quirk for you to use locally, but I hesitate to push it upstream lest it break > other users with the original panel. 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc M52 [Mobility Radeon X1300] [1002:7149] (prog-if 00 [VGA controller]) Subsystem: Lenovo Device [17aa:2005] Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at d8000000 (32-bit, prefetchable) [size=128M] I/O ports at 2000 [size=256] Memory at ee100000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at ee120000 [disabled] [size=128K] Capabilities: <access denied> Kernel modules: radeon The following are the outputs of parsing the EDID information. The information provided varies depending on the querying method. The information also appears to be largely correct (although the internal panel is 14.1" and not 15"). I don't see why xrandr is getting it's information wrong. monitor-get-edid | monitor-parse-edid EISA ID: LEN4040 EDID version: 1.3 EDID extension blocks: 0 Screen size: 30.4 cm x 22.8 cm (14.96 inches, aspect ratio 4/3 = 1.33) Gamma: 2.2 Digital signal # Monitor preferred modeline (60.0 Hz vsync, 48.4 kHz hsync, ratio 4/3, 85 dpi) ModeLine "1024x768" 65 1024 1048 1184 1344 768 771 777 806 -hsync -vsync # Monitor supported modeline (50.0 Hz vsync, 40.3 kHz hsync, ratio 4/3, 85 dpi) ModeLine "1024x768" 54.16 1024 1048 1184 1344 768 771 777 806 -hsync -vsync xrandr --prop | monitor-parse-edid Name: SyncMaster EISA ID: SAM005a EDID version: 1.3 EDID extension blocks: 0 Screen size: 33.8 cm x 27.0 cm (17.03 inches, aspect ratio 5/4 = 1.25) Gamma: 2.4 Analog signal Max video bandwidth: 130 MHz HorizSync 30-81 VertRefresh 56-85 # Monitor preferred modeline (60.0 Hz vsync, 64.0 kHz hsync, ratio 5/4, 96 dpi) ModeLine "1280x1024" 108 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync
(In reply to comment #9) > The following are the outputs of parsing the EDID information. The information > provided varies depending on the querying method. The information also appears > to be largely correct (although the internal panel is 14.1" and not 15"). I > don't see why xrandr is getting it's information wrong. The system bios patches some of the video bios tables at boot up depending on what panel is attached, etc. In your case, it seems to be patching in the wrong ddc line as it used to work correctly with the old panel. The line that gets patched in happens to be the same line as VGA so xrandr reads the same edid from both outputs. It may be that your panel doesn't have an EDID, in which case the ddc line should not be set and the panel info from the bios tables should be used instead. This is what happens when you don't have an external monitor attached as ddc fails. monitor-get-edid uses vbe so the info it generates is not necessarily from an EDID. It's generated by the video bios either from an real EDID or from panel info in the bios tables.
Created attachment 40135 [details] [review] disable ddc on LVDS This patch should work around the issue.
(In reply to comment #11) > Created an attachment (id=40135) [details] > disable ddc on LVDS > > This patch should work around the issue. It does. Thanks. So for the future I need to somehow get the EDID info off the old panel and onto the new one?
(In reply to comment #12) > (In reply to comment #11) > > Created an attachment (id=40135) [details] [details] > > disable ddc on LVDS > > > > This patch should work around the issue. > > It does. Thanks. So for the future I need to somehow get the EDID info off the > old panel and onto the new one? Depends on how the original system was configured. Not all panels have EDIDs. If it did you'd need to figure out why the proper ddc line is not getting patched into the vbios. If it didn't you'd need to figure out why the new one is causing a bogus ddc line to be entered. Can you get copies of the vbios with the old panel and new panels installed? that would clarify things. See this page for how to dump the vbios: http://people.freedesktop.org/~agd5f/get_vbios.txt
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.