Bug 16205

Summary: x1950 pro, image displaced and resized
Product: xorg Reporter: bb <i.filter.your.spam>
Component: Driver/radeonhdAssignee: Luc Verhaegen <lverhaegen>
Status: RESOLVED WONTFIX QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high    
Version: unspecified   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
screenshot
none
Xorg.log of fglrx
none
Xorg.log of radeonhd
none
Xorg.conf
none
Xorg.log fglrx new version
none
Xorg.log radeonhd new version
none
xrandr -v -q output with radeonhd
none
Xorg.log radeonhd xrandr --rate 75
none
Xorg.log radeonhd xrandr --rate75
none
Xorg.log radeonhd xrandr -q --verbose with a "blank" X
none
Xorg.log radeonhd xrandr -q --verbose with a "gnome" X
none
Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906
none
Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906
none
xrandr -q --verbose output with xserver 1.4.99.906
none
xrandr -q --verbose output with xserver 1.4.99.906 and xrandr git version
none
Test patch.
none
xorg.conf that works with radeon/radeonhd and forces the right mode none

Description bb 2008-06-02 13:58:02 UTC
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
Comment 1 Egbert Eich 2008-06-11 21:52:48 UTC
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.
Comment 2 bb 2008-06-17 06:10:59 UTC
Created attachment 17193 [details]
Xorg.log of fglrx
Comment 3 bb 2008-06-17 06:11:23 UTC
Created attachment 17194 [details]
Xorg.log of radeonhd
Comment 4 bb 2008-06-17 06:12:04 UTC
Created attachment 17195 [details]
Xorg.conf
Comment 5 Egbert Eich 2008-07-20 06:51:42 UTC
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!
Comment 6 bb 2008-07-20 14:17:29 UTC
Created attachment 17774 [details]
Xorg.log fglrx new version
Comment 7 bb 2008-07-20 14:18:38 UTC
Created attachment 17775 [details]
Xorg.log radeonhd new version
Comment 8 bb 2008-07-20 14:19:55 UTC
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.


Comment 9 Egbert Eich 2008-07-20 15:15:06 UTC
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?
Comment 10 bb 2008-07-20 15:17:34 UTC
no, I am using 1600x1200 with both drivers
Comment 11 Egbert Eich 2008-07-20 15:54:30 UTC
(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.
Comment 12 bb 2008-07-20 15:58:15 UTC
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?
Comment 13 Egbert Eich 2008-07-20 16:11:21 UTC
(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?
Comment 14 bb 2008-07-20 16:15:32 UTC
Created attachment 17776 [details]
xrandr -v -q output with radeonhd
Comment 15 Egbert Eich 2008-07-21 00:39:39 UTC
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).
Comment 16 Egbert Eich 2008-07-21 07:18:03 UTC
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.
Comment 17 bb 2008-07-26 11:58:06 UTC
I started X with -logverbose 7 and typed xrandr --rate 75.

The image is still displaced.

Here is also the Xorg.log
Comment 18 bb 2008-07-26 11:58:57 UTC
Created attachment 17910 [details]
Xorg.log radeonhd xrandr --rate 75
Comment 19 Egbert Eich 2008-07-28 12:24:42 UTC
(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.
Comment 20 bb 2008-07-30 11:49:23 UTC
sry, startx didn't seem to accept my args.

Here is another try.

Comment 21 bb 2008-07-30 11:50:05 UTC
Created attachment 18007 [details]
Xorg.log radeonhd xrandr --rate75
Comment 22 Egbert Eich 2008-07-30 14:28:27 UTC
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']
Comment 23 bb 2008-07-30 15:01:04 UTC
futher tests aren't a problem, here your requested files
Comment 24 bb 2008-07-30 15:01:48 UTC
Created attachment 18012 [details]
Xorg.log radeonhd xrandr -q --verbose with a "blank" X
Comment 25 bb 2008-07-30 15:02:31 UTC
Created attachment 18013 [details]
Xorg.log radeonhd xrandr -q --verbose with a "gnome" X
Comment 26 Egbert Eich 2008-07-30 21:47:17 UTC
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.
Comment 27 bb 2008-08-01 08:25:02 UTC
Created attachment 18062 [details]
Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906
Comment 28 Egbert Eich 2008-08-02 06:39:17 UTC
The log still shows version 1.4.2.
> X.Org X Server 1.4.2
> Release Date: 11 June 2008
Comment 29 bb 2008-08-02 06:51:43 UTC
Created attachment 18080 [details]
Xorg.log: xrandr --rate 75; xrandr -q --verbose with xserver 1.4.99.906
Comment 30 Egbert Eich 2008-08-02 12:03:55 UTC
(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 ?
Comment 31 bb 2008-08-02 12:15:03 UTC
Created attachment 18085 [details]
xrandr -q --verbose output with xserver 1.4.99.906
Comment 32 Egbert Eich 2008-08-04 06:15:46 UTC
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).
Comment 33 bb 2008-08-04 06:33:36 UTC
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!!!

Comment 34 Egbert Eich 2008-08-04 07:31:44 UTC
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!
Comment 35 bb 2008-08-04 07:56:47 UTC
Created attachment 18106 [details]
xrandr  -q --verbose output with xserver 1.4.99.906 and xrandr git version
Comment 36 bb 2008-08-04 12:43:40 UTC
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?
Comment 37 Egbert Eich 2008-08-04 13:14:29 UTC
(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.
Comment 38 Egbert Eich 2008-08-07 05:41:39 UTC
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.
Comment 39 bb 2008-09-18 09:31:54 UTC
(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
Comment 40 Egbert Eich 2008-09-19 12:23:18 UTC
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!
Comment 41 bb 2008-09-20 01:59:48 UTC
!!! 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
Comment 42 Egbert Eich 2008-09-20 04:31:25 UTC
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.
Comment 43 bb 2009-01-09 10:58:10 UTC
Created attachment 21838 [details]
xorg.conf that works with radeon/radeonhd and forces the right mode
Comment 44 bb 2009-03-18 10:31:21 UTC
no one interested in this bug?
Comment 45 Jeremy Huddleston Sequoia 2011-10-16 15:59:58 UTC
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.
Comment 46 Jeremy Huddleston Sequoia 2011-11-07 15:05:49 UTC
Closing due to lack of response.  Please reopen and move to the Driver/Radeon 
component if this issue persists with xf86-video-ati
Comment 47 Adam Jackson 2018-06-11 20:17:52 UTC
*** 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.