I recently upgraded my system to SuSE 10.0, which uses x.org 6.8.2 and now the dual head configuration for my Thinkpad t40p is not working. I have had my thinkpad configured for xinerama operation for over two years and 3 different SuSE distributions with basically the same configuration. The system "thinks" the secondary monitor is attached and working, but there is no signal output to the secondary display. I can't see any obvious errors in the XOrg.0.log file except for the following message. <snip> (II) RADEON(0): Primary: Monitor -- LVDS Connector -- DVI-D DAC Type -- TVDAC/ExtDAC TMDS Type -- Internal DDC Type -- DVI_DDC (II) RADEON(0): Secondary: Monitor -- CRT Connector -- VGA DAC Type -- Primary TMDS Type -- NONE DDC Type -- VGA_DDC (II) RADEON(0): PLL parameters: rf=2700 rd=12 min=20000 max=35000; xclk=20000 (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled <snip> The log successfully detects the Samsung SyncMaster 730b LCD monitor attached to the vga port and validates the sync modes, but all I get is a black screen on the secondary monitor. Another post suggested that entering the line: Option "MonitorLayout" "LVDS, CRT" to the xorg.conf file would help, but that has not made a difference in my case. Yet another suggested running the commands: xset dpms force off xset dpms force on after X started. Again no success.
Created attachment 3916 [details] xorg.conf Here is the xorg.conf file in use.
Created attachment 3917 [details] Xorg log file Here is the Xorg.o.log file.
I have the exact same symptoms, i.e.: a) secondary monitor and its modes are detected (with the help of MonitorLayout, b) DAC Type for external CRT is Primary, for notebook's LCD is TVDAC/ExtDAC c) External CRT is blank, probably being in DPMS mode "Off" in my HP Compaq nx7000 notebook, equipped with an Ati Mobility Radeon 9200 and running Gentoo's xf86-driver-ati 6.5.7.3 I tried applying the patch (for modular X) mentioned in bug 3621, but it would not apply cleanly. However, I must say that MergeFB mode (i.e. layout "mergedfbicom" in my xorg.conf) works flawlessly, only simple Dual Head (i.e. layout "xineramaicom") exhibits this problem.
Created attachment 4797 [details] /etc/X11/xorg.conf file
Created attachment 4798 [details] /var/log/Xorg.1.log file Log created when running X server with layout "xineramaicom"
Created attachment 4799 [details] /var/log/Xorg.0.log Log created when running X server with layout "mergedfbicom" (CRT is working properly in this case)
Georgios, do you use X.org 6.8 or 6.9/7.0? There appears to be a different bug, introduced in 6.9, wherein MergedFB modes work (modulo bug 5565), while Xinerama/plain dual-head layouts produce no signal on the external monitor (bugs 5571, 6165). Russell, did you try MergedFB instead of Xinerama?
(In reply to comment #7) > Georgios, do you use X.org 6.8 or 6.9/7.0? X.org 7.0.0, as it appears in the beginning of the Xorg.*.log files I attached.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
I have the same problems with a X300SE PCIE DVI+VGA card. So the problem is still present 16 months after it was reported here...
Same issue here, using an ATI Technologies Inc Mobility Radeon HD 3650 in a Thinkpad W500. Starting out with either a DVI or a VGA external display connected works fine, but when I try to switch to the other kind of display (VGA or DVI), the display is correctly detected but cannot be activated. For instance, having connected a DVI display to begin with, I tried to activate a VGA display - no use. Here's my xrandr output when I attempted to do so: $ xrandr --output VGA-0 --mode 1600x1200 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 150 (RANDR) Minor opcode of failed request: 21 () Serial number of failed request: 28 Current serial number in output stream: 28 Also tried 'xset dpms force off/on', no use.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.
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.