Created attachment 16877 [details] screenshot Windows: the image perfectly fills the screen OSX86: the image perfectly fills the screen Linux (fglrx): the images perfectly fills the screen Linux (radeonhd): the image is some kind of displaced and resized I have got a x1950 Pro PCIE with 512MB of GDDR3 RAM (Gecube). pls contact me, if you need any further information
You are using a CRT. On those you may have to use the OSD to center/size the image correctly. I would like to find out which mode is used (ie a monitor suggested one or one calculated using CVT). Please provide a log file (generated with -logverbose 7). Maybe you can also provide a log generated by the fglrx driver. Assigning to reporter for feedback, please turn back to me hen done.
Created attachment 17193 [details] Xorg.log of fglrx
Created attachment 17194 [details] Xorg.log of radeonhd
Created attachment 17195 [details] Xorg.conf
There seems to be a problem with the modes list: (II) RADEONHD(0): Modeline "1600x1200"x74.9 205.50 1600 1720 1893 2186 1200 1203 1207 1255 -hsync +vsync (94.0 kHz) (II) RADEONHD(0): Modeline "1600x1200"x75.0 202.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (93.8 kHz) (II) RADEONHD(0): Modeline "1600x1200"x70.0 190.75 1600 1716 1889 2178 1200 1203 1207 1252 -hsync +vsync (87.6 kHz) (II) RADEONHD(0): Modeline "1600x1200"x70.0 189.00 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (87.5 kHz) The second and fourth mode originate from a detailed timing section in an EDID block: (II) RADEONHD(0): Supported additional Video Mode: (II) RADEONHD(0): clock: 202.5 MHz Image Size: 380 x 285 mm (II) RADEONHD(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEONHD(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 (II) RADEONHD(0): Supported additional Video Mode: (II) RADEONHD(0): clock: 189.0 MHz Image Size: 380 x 285 mm (II) RADEONHD(0): h_active: 1600 h_sync: 1664 h_sync_end 1856 h_blank_end 2160 h_border: 0 (II) RADEONHD(0): v_active: 1200 v_sync: 1201 v_sync_end 1204 v_blanking: 1250 v_border: 0 while the 2nd and 3rd seem to be calculated from the 'supported future video modes in the EDID block: (II) RADEONHD(0): #0: hsize: 1600 vsize 1200 refresh: 75 vid: 20393 (II) RADEONHD(0): #1: hsize: 1600 vsize 1200 refresh: 70 vid: 19113 The former ones should have precedence over the latter ones. The latter ones don't appear in the fglrx log at all. I assume since a suboptimal mode is picked the mode is not optimal and needs some intervention. The modes list is provided by randr, thus this should not be a driver issue. Your server is quite old, chances are high that this has been fixed already. Please retry with a later server and reopen when the problem still exists. Thanks!
Created attachment 17774 [details] Xorg.log fglrx new version
Created attachment 17775 [details] Xorg.log radeonhd new version
I upgraded to xorg-server 1.4.2, the problem still exists: fglrx: works fine radeonhd: screen still displaced I also uploaded new Xorg.log files.
Could it be that you are using 1600x1200 on fglrx while you are using 1280x1024 on radeonhd? (II) RADEONHD(0): Output DVI-I_1/analog using initial mode 1280x1024 **) fglrx(0): *Mode "1600x1200": 202.5 MHz (scaled from 0.0 MHz), 93.8 kHz, 75.0 Hz (II) fglrx(0): Modeline "1600x1200"x75.0 202.50 1600 1664 1856 2160 1200 1201 1204 1250 (93.8 kHz) so you are comparing apples and pears?
no, I am using 1600x1200 with both drivers
(In reply to comment #10) > no, I am using 1600x1200 with both drivers > Why do you get the message that the initial mode is 1280x1024? Even your old (verbose 7) log in attachment #17194 [details] shows this: RRCrtc #0 [rhd CRTC 1]: active 1 [1] mode 1280x1024 (1280x1024) +0+0 This message is only printed in a verbose log, so it doesn't appear in the latest radeonhd log.
gdm seams to switch to 1280x1024, but i can guarantee that gnome is running at 1600x1200 after the login do you need any futher information?
(In reply to comment #12) > gdm seams to switch to 1280x1024, but i can guarantee that gnome is running at > 1600x1200 after the login > > do you need any futher information? > I fail to find any indication of the chosen 1600x1200 mode in either the old or the new radeonhd log file. What does xrandr -v -q report?
Created attachment 17776 [details] xrandr -v -q output with radeonhd
Ok, there are 4 modes listed for 1600x1200 as the refresh rates are different. Those 4 modes correspond to the modes in the log file. The one with the '*' is the current one. If you look at comment #5 it corresponds to the one that is calculated (not derived from the detailed timing section). Why gnome/randr picks this one is beyond me. Please try and change the refresh rate to 75 Hz - this should pick the "1600x1200"x74.9 205.50 1600 1720 1893 2186 1200 1203 1207 1255 -hsync +vsync (94.0 kHz) mode which is the one listed in the detailed timing section of the monitor and which seems to be the one picked by the fglrx driver. See if this makes a difference. If not please attach a logverbose 7 log file with a new radeonhd driver. The later driver show exactly the mode that's been programmed to the hw in verbose 7 mode (please set the mime type of the attachment to text/plain).
Sorry, I messed up... 'xrandr --rate 75.0' should pick the mode: (II) RADEONHD(0): Modeline "1600x1200"x75.0 202.50 1600 1664 1856 2160 1200 1201 1204 1250 +hsync +vsync (93.8 kHz) which is from the detailed timings in DDC.
I started X with -logverbose 7 and typed xrandr --rate 75. The image is still displaced. Here is also the Xorg.log
Created attachment 17910 [details] Xorg.log radeonhd xrandr --rate 75
(In reply to comment #18) > Created an attachment (id=17910) [details] > Xorg.log radeonhd xrandr --rate 75 > Unfortlately the attached log file is not useful as X wasn't run with -logverbose 7 as requested in comment #15. I need to see which mode is actually sent to the crtc. This information is only contained when the Xserver is running in verbose level 7.
sry, startx didn't seem to accept my args. Here is another try.
Created attachment 18007 [details] Xorg.log radeonhd xrandr --rate75
Thanks for the log file! This is indeed strange: the mode that's set is different from the ones probed. It looks like some other 1600x1200 mode has been added that didn't originate from the monitor. Could you please do two things: 1. run xrandr -q --verbose and attach the log file. 2. start a 'bare' Xserver (I usually do: X -logverbose 7 & sleep 5; xterm -display) and run the same xrandr -q --verbose command in the xterm. Sorry that I have to ask for so many tests but this is the only way one can understand what's going on. [With startx you pass extra server options like this: 'startx -- -logverbose 7']
futher tests aren't a problem, here your requested files
Created attachment 18012 [details] Xorg.log radeonhd xrandr -q --verbose with a "blank" X
Created attachment 18013 [details] Xorg.log radeonhd xrandr -q --verbose with a "gnome" X
Thanks for the logs! I've checked the output and it looks like the modes that are passed to the CRTC have no resemblance to the modes that were advertised by the monitor. I have no idea where these modes are coming from, but they are very different from any of the ones in the list of monitor gathered modes. Now you are using Xserver 1.4.2. Would it be possible to move to one closer to the current GIT master? I've seen different results from version 1.4.99.905. Maybe this would be worth a try.
Created attachment 18062 [details] Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906
The log still shows version 1.4.2. > X.Org X Server 1.4.2 > Release Date: 11 June 2008
Created attachment 18080 [details] Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906
(In reply to comment #29) > Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906 Could you please do exactly the same again and attach the output of xrandr -q --verbose ?
Created attachment 18085 [details] xrandr -q --verbose output with xserver 1.4.99.906
OK, this version of xrandr doesn't supply all the information I'm looking for. Please get xrandr from Xorg's git master git://git.freedesktop.org/git/app/xrandr build them and rerun xrandr from there. Also please run xrandr --output DVI-I_1/analog --mode 0x42. This command should let you one of the modes advertised by the monitor. Check if this one fits better. If you are on a 64bit system the latter command will only work when you have the very latest version of xrandr from git master (with the patch I've pushed today).
hi, I think the git address is git://git.freedesktop.org/git/xorg/app/xrandr. xrandr --output DVI-I_1/analog --mode 0x42. Give me to expected result: !!!Image fits perfectly and is neither resized nor displaced!!!
Yea, you are right about the git address :) OK, sounds good! However I wonder why mode 0x42 isn't the preferred mode. Could you please use these latest xrandr bits to recreate the output of attachment #18085 [details]? The output of the later versions of xrandr should mark the current and preferred mode in the verbose output, too. In the older version (like the one you had installed) only the non-verbose output had this information and this didn't uniquely mark modes by their XIDs but only by name and refresh rate. However since names are not really unique (not even names + refresh rates) one can only identify a mode completely by it's XID. Mode 0x42 is the first mode from the detailed timing section in the DDC block from your monitor. That randr doesn't make it the preferred one seems to be a problem of the randr layer itself. There is nothing that the driver can do here. After you've attached the xrandr output i think this ticket can be closed (at least from the standpoint of this driver). Thanks!
Created attachment 18106 [details] xrandr -q --verbose output with xserver 1.4.99.906 and xrandr git version
If you close this bug, could you please open a new bugticket (may randr or whatever?)? I want this bug to be fixed and I don't know where to open the new bugticket. Do you know why randr works properly with the fglrx driver?
(In reply to comment #36) > If you close this bug, could you please open a new bugticket (may randr or > whatever?)? > I want this bug to be fixed and I don't know where to open the new bugticket. > Let me take a look at the code myself first. > > Do you know why randr works properly with the fglrx driver? > To my knowledge fglrx doesn't support RandR 1.2 and above, yet. The driver there is much more in control of things.
I've looked at the code and still fully understand why the modes list is ordered wrong. One thing to try: can you comment out the line: Modes "1600x1200" as this will pick the first mode of this size (read name) in the list and make it the preferred one. The list should already be sorted so that the monitor preferred mode is the first one in the list of modes with the same name, but ... well.
(In reply to comment #38) > I've looked at the code and still fully understand why the modes list is > ordered wrong. > One thing to try: can you comment out the line: > Modes "1600x1200" > as this will pick the first mode of this size (read name) in the list and make > it the preferred one. The list should already be sorted so that the monitor > preferred mode is the first one in the list of modes with the same name, but > ... well. > sry for the slow answer, when I comment out Modes "1600x1200", X picks 1920x1440 which is a quite strange mode
Created attachment 19023 [details] [review] Test patch. Since your monitor doesn't specify that the first detailed timing section is the preferred one you might actually have to set the mode. So you may want to leave the 'Modes' line in. I might have found something. Could you please apply this patch and see if the situation improves? Thanks!
!!! you fixed it !!!! with the patch applied everything fits perfectly. I have a similiar problem with the xf86-video-radeon driver, could we get this also fixed? thx for your efforts
bb: thanks for the test. This is actually not the fix, yet. I'm assigning this to Luc Verhaegen as this bug is in code that he originally wrote. The point is: the function that I've commented out uses modes from the standard timing section in an EDID block. Depending on the EDID version and the flags set in EDID different stragies should be applied to obtain a full mode line. The code in the driver only picks a CVT mode line. However it may be necessary to use a GTF or DMT timings. I should have GTF code sitting around which I could add.
Created attachment 21838 [details] xorg.conf that works with radeon/radeonhd and forces the right mode
no one interested in this bug?
Does this issue occur with the preferred ati driver (xf86-vide-ati)? If so, please move this to the Driver/Radeon component. Development of radeonhd has pretty much halted and development focus is on the ati driver. Please see http://www.x.org/wiki/radeonhd If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.
Closing due to lack of response. Please reopen and move to the Driver/Radeon component if this issue persists with xf86-video-ati
*** Bug 20999 has been marked as a duplicate of this bug. ***
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.