I have an ATI X800 XL (PCIe) with DVI and VGA plugs and an LCD monitor Viewsonic VG191 1280x1024 with the same connectors. These are used on a Athlon x86_64 machine running Fedora rawhide version which features xorg 7.0. Here the information of current packages: Kernel: Linux 2.6.15-1.1826.2.10_FC5 xorg: xorg-x11-drv-ati-6.5.7.3-3.2 (for more information see http://www.di.ens.fr/users/castagna/Xorg.0.log ... I do not see how to add an attachment here) When I connect the Viewsonic monitor only via the DVI cable the monitor is not recognized (it is considered a CRT, gives a synch out of range and the resolution is dropped to a very low reslution, 640x480 I guess: see the log file below), while if I connect only **or also** the VGA, then the resolution was correctly set to 1280x1024 (even if I manually select the signal on the DVI port). After several tries (forcing panel size, etc, etc) I found that the problem goes away by using Option "MergedFB" "false" since I noticed that when the VGA cable was connected the MergedFB was executed instead of the monitor recognition (when VGA-cable is pluged). If I comment out the line above in my xorg.cong I obtain the following log error: http://www.di.ens.fr/users/castagna/Xorg.0.log.bug My current xorg.conf file can be found at http://www.di.ens.fr/users/castagna/xorg.conf Hope it helps.
Created attachment 4707 [details] xorg.conf file
Created attachment 4708 [details] Log when resolution is ok
Created attachment 4709 [details] Log when resolution is wrong (i.e. MergedFB=true)
yes ... I discovered how to add attachments :-)
looks like your DDC lines are reversed. try setting: Option "ReverseDDC" "TRUE"
> looks like your DDC lines are reversed. try setting: > Option "ReverseDDC" "TRUE" It does not work. Same problem. Notice that it does not look as if X inverts the two DDC connectors, but rather that when the monitor is not connected to the VGA port the MergedFB mode is not forced off and that it considers the monitor as a CRT. Indeed you diff my Xorg.0.log.bug and Xorg.0.log you will notice the following: < (II) RADEON(0): Validating CRTC2 modes for MergedFB ------------ < (II) RADEON(0): CRT2 Monitor: Using hsync range of 28.00-33.00 kHz < (II) RADEON(0): CRT2 Monitor: Using vrefresh range of 43.00-72.00 Hz < (II) RADEON(0): Clock range: 20.00 to 500.00 MHz < (II) RADEON(0): Not using default mode "640x350" (hsync out of range) < (II) RADEON(0): Not using default mode "320x175" (bad mode clock/interlace/doublescan) etc, etc. This gave me the cue to disable MergedFB Ah, FYI my card is a Gigabyte GV-RX80L256V Fanless X800 XL PCI-Express, and my LCD and DVI cable worked flawlessly on the previous machine they were installed on.
Bug 6796 has similar DVI output problem with another X800 card. Updating version to 7.2 (still happens).
Actually, I just noticed on my X800 the problem only occurs when both DVI and VGA are in use, not the other way around. So, with only DVI connected 1280x1024 is displayed just fine. Could you Giuseppe check what's the situation with the current driver? I find the behavior the same with both 6.6.2 and the latest GIT.
Created attachment 8560 [details] With both DVI and VGA attached, I get only 640x480.
Created attachment 8561 [details] With only DVI attached, I get full resolution.
(changed the summary to reflect the behavior on my X800, feel free to change it back if the original bug seems to be there... also if the original bug is fixed you, it might be wise to mark this as fixed and file a new bug on my problem)
Actually, I no longer have the same hardware as one year ago. So I cannot proceed to any test. Sorry
Hmm, actually this works if I attach the VGA to some proper monitor instead of a crappy VGA to S-Video adapter, so I guess it works for all true multi-monitor setups. So, marking as fixed! I don't think it's the driver's problem to choose automatically whether a bigger resolution is used on the primary monitor and a smaller resolution on the secondary, ie. it should be configurable elsewhere (currently just xorg.conf).
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.