Bug 14500 - External monitor does not display native resolution
External monitor does not display native resolution
Status: NEW
Product: xorg
Classification: Unclassified
Component: Driver/Radeon
unspecified
x86 (IA32) Linux (All)
: medium normal
Assigned To: xf86-video-ati maintainers
Xorg Project Team
2011BRB_Reviewed
:
: 13605 18344 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-14 12:42 UTC by Konstantin Svist
Modified: 2011-10-17 07:16 UTC (History)
7 users (show)

See Also:


Attachments
Xorg.0.log (109.98 KB, text/x-log)
2008-02-14 12:42 UTC, Konstantin Svist
no flags Details
xorg.conf and Xorg.0.log for 2 tests: defaults & ForceReduced/Modeline (11.86 KB, application/x-bzip2)
2008-02-27 15:06 UTC, Konstantin Svist
no flags Details
More verbose logging. (722 bytes, patch)
2008-03-03 01:09 UTC, Egbert Eich
no flags Details | Splinter Review
patch + logverbose -7 (73.88 KB, text/x-log)
2008-03-10 12:43 UTC, Konstantin Svist
no flags Details
logverbose 7 - 2nd try (73.50 KB, text/plain)
2008-03-28 13:34 UTC, Konstantin Svist
no flags Details
logverbose 7 - 3rd try (128.02 KB, text/plain)
2008-03-31 11:28 UTC, Konstantin Svist
no flags Details
logverbose 7 - 4th try (13.24 KB, application/x-bzip2)
2008-03-31 13:32 UTC, Konstantin Svist
no flags Details
logverbose 7 - 5th try (127.82 KB, text/plain)
2008-04-03 14:26 UTC, Konstantin Svist
no flags Details
logverbose 7 - without outputorder, without leftof (78.66 KB, text/plain)
2008-08-04 14:58 UTC, Martin Nowack
no flags Details
logverbose 7 - without outputorder, with leftof (78.74 KB, text/plain)
2008-08-04 15:01 UTC, Martin Nowack
no flags Details
logverbose 7 - with outputorder, without leftof (78.06 KB, text/plain)
2008-08-04 15:02 UTC, Martin Nowack
no flags Details
logverbose 7 - with outputorder, with leftof (78.13 KB, text/plain)
2008-08-04 15:02 UTC, Martin Nowack
no flags Details
Xorg.0.log showing radeonhd claiming support of 1400x1050 while the LCD is up to 1280x1024 only (122.55 KB, text/x-log)
2008-12-21 09:56 UTC, Peter Hercek
no flags Details
Xorg.0.log with EDID of quirky monitor (185.16 KB, patch)
2009-09-09 16:41 UTC, Konstantin Svist
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Svist 2008-02-14 12:42:10 UTC
My external monitor has native resolution 1680x1050. Autodetection appears to use mode 1280x1024 79KHz/75Hz (read from monitor's menu).
I've tried getting help in the #radeonhd IRC channel in December - setting the ModeLine in xorg.conf seemed to force 1680x1050 mode, but the image was still not displayed correctly (it was squished/offset horizontally).


This problem does not appear with current fglrx driver, although it appeared with some older drivers. (Don't know if this information is helpful in this case..)


Hardware:
laptop - Dell Inspiron e1505
videocard - 
01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility X1400
Comment 1 Konstantin Svist 2008-02-14 12:42:48 UTC
Created attachment 14316 [details]
Xorg.0.log
Comment 2 Egbert Eich 2008-02-16 06:30:16 UTC
The detailed timing in the EDID block lists a 720x480 mode while the future timing list includes a 1680x1050 mode. 
What mode line did you use that gave you the 'squished' mode? What exactly do you mean by that? Did you see a 1680x1050 screen which did not fully cover the surface? What did the osd menue say about this mode?
Do you have a virtual size specified in your config?
Comment 3 Konstantin Svist 2008-02-18 18:40:36 UTC
(In reply to comment #2)
> The detailed timing in the EDID block lists a 720x480 mode while the future
> timing list includes a 1680x1050 mode. 
> What mode line did you use that gave you the 'squished' mode? What exactly do
> you mean by that? Did you see a 1680x1050 screen which did not fully cover the
> surface? What did the osd menue say about this mode?
> Do you have a virtual size specified in your config?
> 

Correction: when 1680x1050 mode is forced, the image still looks like 1280x1024 resolution, and the mouse disappears off left and right sides of the monitor (instead, it's supposed to either jump over to panel or stop moving).

This mode is achieved by setting these 2 options:

Section "Device"
 Option "ForceReduced" "True"
EndSection

Section "Monitor"
 Modeline "1680x1050R"  119.00  1680 1728 1760 1840  1050 1053 1059 1080 +hsync -vsync
EndSection


The OSD says the resolution is 1680x1050, with 65KHz/59.7Hz (sometimes says 59.9Hz)

Yes, virtual size is specified in Screen/Display: Virtual 3360 1050
Comment 4 Egbert Eich 2008-02-19 01:21:02 UTC
It looks like your monitor is connected thru a analog input. Did you try the 'autoadjust' function in the osd menue? Did you try to fiddle with the +/-v/hsync flags?
Comment 5 Konstantin Svist 2008-02-19 13:39:18 UTC
(In reply to comment #4)
> It looks like your monitor is connected thru a analog input. Did you try the
> 'autoadjust' function in the osd menue? Did you try to fiddle with the
> +/-v/hsync flags?
> 

Correct, the monitor is connected through VGA out.
I tried autoadjust in all +/-v/hsync modes - they all looked the same.

Side note (may be helpful): when using fglrx, OSD shows 65KHz/60.3Hz
Comment 6 Egbert Eich 2008-02-27 05:37:05 UTC
The monitor itself reports a 720x780 mode as native resolution:

(II) RADEONHD(0): #0: hsize: 640  vsize 360  refresh: 70  vid: 51761
(II) RADEONHD(0): #1: hsize: 640  vsize 480  refresh: 70  vid: 18993
(II) RADEONHD(0): #2: hsize: 800  vsize 600  refresh: 70  vid: 19013
(II) RADEONHD(0): #3: hsize: 1024  vsize 768  refresh: 72  vid: 19553
(II) RADEONHD(0): #4: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) RADEONHD(0): #5: hsize: 1600  vsize 1200  refresh: 60  vid: 16553
(II) RADEONHD(0): #6: hsize: 1680  vsize 1050  refresh: 60  vid: 179
(II) RADEONHD(0): Supported additional Video Mode:
(II) RADEONHD(0): clock: 28.0 MHz   Image Size:  408 x 306 mm
(II) RADEONHD(0): h_active: 720  h_sync: 738  h_sync_end 846 h_blank_end 900 h_border: 0
(II) RADEONHD(0): v_active: 480  v_sync: 490  v_sync_end 492 v_blanking: 525 v_border: 0
(II) RADEONHD(0):  LCD MONITOR
(II) RADEONHD(0): Ranges: V min: 55  V max: 76 Hz, H min: 30  H max: 82 kHz, PixClock max 140 MHz

The mode line listed below ("1680x1050R") doesn't appear anywhere in the log. So it doesn't seem to be used. Please make sure that this monitor section is referenced correctly and that the mode is used.

Reassigning to reporter for further tests.
Comment 7 Matthias Hopf 2008-02-27 06:08:21 UTC
please also attach your config - if you don't have a Option "monitor-*" in your device section, the monitor section (and with it its modeline) isn't used, thus 1680x1050R remains unknown. These *R reduced modes are only known automatically in non-RandR case.
Comment 8 Konstantin Svist 2008-02-27 15:06:32 UTC
Created attachment 14624 [details]
xorg.conf and Xorg.0.log for 2 tests: defaults & ForceReduced/Modeline

Attaching xorg.conf and Xorg.0.log for 2 test cases:
1: defaults (no special config) in xorg.conf
Monitor uses 1280x1024 resolution

2: ForceReduced and Modeline are set
Monitor reports 1680x1050 on OSD, but looks like 1280x1024

Any other settings you want me to try?
Comment 9 Konstantin Svist 2008-02-28 23:40:27 UTC
Ummm... am I supposed to reassign the bug back to previous person?
Comment 10 Egbert Eich 2008-03-03 01:09:29 UTC
Created attachment 14781 [details] [review]
More verbose logging.

This is indeed strange.
Could you please apply the attached patch and run the again using 
'-logverbose 7' as command line argument (like in test2).
Then please attach the log from the Xserver here.
Hint: you can run a 'bare' Xserver from a console. To terminate it, simply press
Ctrl-Alt-Backspace. 
Then please reassign this back to me. Thanks.
Comment 11 Konstantin Svist 2008-03-10 12:43:29 UTC
Created attachment 15011 [details]
patch + logverbose -7
Comment 12 Egbert Eich 2008-03-26 16:18:22 UTC
Unfortunately the attached log does not contain the information this patch is supposed to print.
This patch has been committed upstream now. Some other fixes have been pushed upstream which might fix your problem.
Could you please update your git sources and retest? If the problem still exists please attach a -logverbose 7 log.
[Reassingning to reporter for feedback (please assign it back to me when done)] 
Comment 13 Konstantin Svist 2008-03-28 13:34:41 UTC
Created attachment 15548 [details]
logverbose 7 - 2nd try

The problem persists, unfortunately :(
Here's the new log file (from runlevel 3 ran "# Xorg -logverbose 7")
Comment 14 Egbert Eich 2008-03-31 08:26:10 UTC
Konstantin, your driver prints out:
(II) RADEONHD: version 1.0.0, built from git branch master, commit 861debbf
This is a version from Dec, 18th, 2007.
Please make sure you try with the latest driver.
When done please reassign back to me.
Comment 15 Konstantin Svist 2008-03-31 09:28:16 UTC
(In reply to comment #14)
> Konstantin, your driver prints out:
> (II) RADEONHD: version 1.0.0, built from git branch master, commit 861debbf
> This is a version from Dec, 18th, 2007.
> Please make sure you try with the latest driver.
> When done please reassign back to me.
> 


I did a "git clone ..." as it says on http://wiki.x.org/wiki/radeonhd. (I messed up the directory earlier, so I couldn't do a "git pull")
After that, created _b directory and ran "../autogen.sh" then "make" from it. Then, as root (from _b), ran "make install".

What was I doing wrong?

Comment 16 Egbert Eich 2008-03-31 09:32:36 UTC
Can you use gitk to look at the top commit? The driver probably didn't get installed at the correct location. Check your log file for the location of the driver module and make sure 'make install' installs there.
Comment 17 Julien Cristau 2008-03-31 09:38:32 UTC
On Mon, Mar 31, 2008 at 09:28:17 -0700, bugzilla-daemon@freedesktop.org wrote:

> --- Comment #15 from Konstantin Svist <fry.kun@gmail.com>  2008-03-31 09:28:16 PST ---
> I did a "git clone ..." as it says on http://wiki.x.org/wiki/radeonhd. (I
> messed up the directory earlier, so I couldn't do a "git pull")
> After that, created _b directory and ran "../autogen.sh" then "make" from it.
> Then, as root (from _b), ran "make install".
> 
> What was I doing wrong?
> 
You probably need to pass --prefix=/usr to autogen.sh, to get your
driver installed in the right place.  By default it gets installed in
/usr/local, but your server looks for it in
/usr/lib/xorg/modules/drivers.  Or just copy it manually to the proper
directory.

Cheers,
Julien
Comment 18 Konstantin Svist 2008-03-31 09:45:02 UTC
(In reply to comment #17)
> On Mon, Mar 31, 2008 at 09:28:17 -0700, bugzilla-daemon@freedesktop.org wrote:
> 
> > --- Comment #15 from Konstantin Svist <fry.kun@gmail.com>  2008-03-31 09:28:16 PST ---
> > I did a "git clone ..." as it says on http://wiki.x.org/wiki/radeonhd. (I
> > messed up the directory earlier, so I couldn't do a "git pull")
> > After that, created _b directory and ran "../autogen.sh" then "make" from it.
> > Then, as root (from _b), ran "make install".
> > 
> > What was I doing wrong?
> > 
> You probably need to pass --prefix=/usr to autogen.sh, to get your
> driver installed in the right place.  By default it gets installed in
> /usr/local, but your server looks for it in
> /usr/lib/xorg/modules/drivers.  Or just copy it manually to the proper
> directory.
> 
> Cheers,
> Julien
> 


You're right, it gets installed to /usr/local. Somehow, though, there are symbolic links in the /usr/lib.. that point to /opt/radeonhd/lib/xorg/modules/drivers/radeon_drv.*
I'll go clean it up and see what changes :)
Comment 19 Konstantin Svist 2008-03-31 11:28:23 UTC
Created attachment 15585 [details]
 logverbose 7 - 3rd try

Okay, I think it's the right one this time :)
Comment 20 Egbert Eich 2008-03-31 12:43:34 UTC
Yes, this is better :)
So you are still seeing the problem with the new driver?
Please try what happens when you comment out the 
Virtual 3360 1050
in your config file.
Comment 21 Konstantin Svist 2008-03-31 13:32:19 UTC
Created attachment 15587 [details]
logverbose 7 - 4th try

Unfortunately, yes - the problem still exists.

Xorg.0.log.virt: same as previous, except last time I forgot to "rmmod fglrx", though it didn't seem to have any noticeable effect.
Xorg.0.log.novirt: Virtual setting is commented out
Comment 22 Egbert Eich 2008-03-31 14:59:03 UTC
(In reply to comment #21)

> Xorg.0.log.virt: same as previous, except last time I forgot to "rmmod fglrx",

Please don't load the fglrx module at all after boot. Even if it has been unloaded it may have done some settings which don't agree with the radeonhd driver.

Please test with a freshly booted system - without fglrx being loaded prior to running radeonhd.
Please also remove 
 Option         "RightOf" "Panel"
to get clone mode for this test.
Comment 23 Konstantin Svist 2008-04-03 14:26:25 UTC
Created attachment 15666 [details]
logverbose 7 - 5th try

Here you go. I didn't notice any differences
Comment 24 Martin Nowack 2008-04-09 03:03:45 UTC
Ok, I've got the same problem here with my DELL screen.

I think the cause (or the workaround) is the RROutputOrder option in the xorg.conf.

Because the following.
If I've got the RROutputOrder enabled, there is the following result (just a snip):

(II) RADEONHD(0): Manufacturer's mask: 0
(II) RADEONHD(0): Supported Future Video Modes:
(II) RADEONHD(0): #0: hsize: 1280  vsize 1024  refresh: 60  vid: 32897
(II) RADEONHD(0): #1: hsize: 1152  vsize 864  refresh: 75  vid: 20337
(II) RADEONHD(0): Supported additional Video Mode:
(II) RADEONHD(0): clock: 146.2 MHz   Image Size:  434 x 270 mm
(II) RADEONHD(0): h_active: 1680  h_sync: 1784  h_sync_end 1960 h_blank_end 2240 h_border: 0
(II) RADEONHD(0): v_active: 1050  v_sync: 1053  v_sync_end 1059 v_blanking: 1089 v_border: 0
(II) RADEONHD(0): Serial No: 
(II) RADEONHD(0): Ranges: V min: 56  V max: 75 Hz, H min: 30  H max: 83 kHz, PixClock max 150 MHz
(II) RADEONHD(0): Monitor name: DELL 2005FPW
(II) RADEONHD(0): EDID (in hex):
(II) RADEONHD(0): 	00ffffffffffff0010ac08e04c564638
(II) RADEONHD(0): 	0f1001036e2b1b78ea0195a3574c9c25
(II) RADEONHD(0): 	125054a54b008180714f010101010101
(II) RADEONHD(0): 	01010101010121399030621a274068b0
(II) RADEONHD(0): 	3600b20e1100001c000000ff00503635
(II) RADEONHD(0): 	33373634433846564c0a000000fd0038
(II) RADEONHD(0): 	4b1e530f000a202020202020000000fc
(II) RADEONHD(0): 	0044454c4c20323030354650570a0001
>>>>>> ############################################
(II) RADEONHD(0): rhdRROutputModeValid: Output VGA_1 : 800x600
(II) RADEONHD(0): FUNCTION: RHDRRModeFixup
(II) RADEONHD(0): FUNCTION: DACModeValid
(II) RADEONHD(0): rhdRROutputModeValid: 800x600 -> Status 0
(II) RADEONHD(0): rhdRROutputModeValid: Output VGA_1 : 640x480


But without! the RROutputOrder the following is added at the sharp line:

(II) RADEONHD(0): EDID vendor "DEL", prod id 57352
(II) RADEONHD(0): Using EDID range info for horizontal sync
(II) RADEONHD(0): Using EDID range info for vertical refresh
(II) RADEONHD(0): Printing DDC gathered Modelines:
(II) RADEONHD(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
(II) RADEONHD(0): Modeline "800x600"x0.0   40.00  800 840 968 1056  600 601 605 628 +hsync +vsync (37.9 kHz)
(II) RADEONHD(0): Modeline "640x480"x0.0   31.50  640 656 720 840  480 481 484 500 -hsync -vsync (37.5 kHz)
(II) RADEONHD(0): Modeline "640x480"x0.0   25.20  640 656 752 800  480 490 492 525 -hsync -vsync (31.5 kHz)
(II) RADEONHD(0): Modeline "720x400"x0.0   28.32  720 738 846 900  400 412 414 449 -hsync +vsync (31.5 kHz)
(II) RADEONHD(0): Modeline "1280x1024"x0.0  135.00  1280 1296 1440 1688  1024 1025 1028 1066 +hsync +vsync (80.0 kHz)
(II) RADEONHD(0): Modeline "1024x768"x0.0   78.80  1024 1040 1136 1312  768 769 772 800 +hsync +vsync (60.1 kHz)
(II) RADEONHD(0): Modeline "1024x768"x0.0   65.00  1024 1048 1184 1344  768 771 777 806 -hsync -vsync (48.4 kHz)
(II) RADEONHD(0): Modeline "800x600"x0.0   49.50  800 816 896 1056  600 601 604 625 +hsync +vsync (46.9 kHz)
(II) RADEONHD(0): Modeline "1280x1024"x59.9  109.00  1280 1368 1496 1712  1024 1027 1034 1063 -hsync +vsync (63.7 kHz)
(II) RADEONHD(0): Modeline "1152x864"x74.8  104.00  1152 1224 1344 1536  864 867 871 905 -hsync +vsync (67.7 kHz)

And now the correct option is selected.

It is the latest git (60dc7e04) and xorg-server 2:1.4.1~git20080131-1ubuntu6.

Hope that helps.
Comment 25 Martin Nowack 2008-04-16 00:46:26 UTC
Just some more information to get that thing down.

I've used the latest git and started without the external monitor attached and Xorg -logverbose 7. 

With RROutputOrder set to PANEL:

(II) RADEONHD(0): Output PANEL connected
(II) RADEONHD(0): Output VGA_1 disconnected
(II) RADEONHD(0): Output DVI-D_1 disconnected
(II) RADEONHD(0): Output PANEL using initial mode 1400x1050
(II) RADEONHD(0): RandR 1.2 support enabled
(==) RADEONHD(0): RGB weight 888
(==) RADEONHD(0): Default visual is TrueColor
(==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0)
(II) RADEONHD(0): FUNCTION: RHDGetVirtualFromConfig
(II) RADEONHD(0): FUNCTION: DxFBValid: CRTC 1
(II) RADEONHD(0): FUNCTION: DxFBValid: CRTC 2
(II) RADEONHD(0): Using 1400x1400 Framebuffer with 1408 pitch
(II) RADEONHD(0): ScanoutBuffer at offset 0x00008000 (size = 0x00785000)
(**) RADEONHD(0): Display dimensions: (290, 210) mm
(**) RADEONHD(0): DPI set to (122, 169)

And in the second try without the RROutputOrder:
(II) RADEONHD(0): Output VGA_1 disconnected
(II) RADEONHD(0): Output PANEL connected
(II) RADEONHD(0): Output DVI-D_1 disconnected
(II) RADEONHD(0): Output PANEL using initial mode 1400x1050
(II) RADEONHD(0): RandR 1.2 support enabled
(==) RADEONHD(0): RGB weight 888
(==) RADEONHD(0): Default visual is TrueColor
(==) RADEONHD(0): Using gamma correction (1.0, 1.0, 1.0)
(II) RADEONHD(0): FUNCTION: RHDGetVirtualFromConfig
(II) RADEONHD(0): FUNCTION: DxFBValid: CRTC 1
(II) RADEONHD(0): FUNCTION: DxFBValid: CRTC 2
(II) RADEONHD(0): Using 1400x1400 Framebuffer with 1408 pitch
(II) RADEONHD(0): ScanoutBuffer at offset 0x00008000 (size = 0x00785000)
(==) RADEONHD(0): DPI set to (96, 96)


The strange difference is the dpi calculation:
With the RROutputOrder: DPI set to (122, 169)
Without: DPI set to (96, 96)

Shouldn't there be no difference when no additional screen is attached?

Thanks for help.
Comment 26 Konstantin Svist 2008-04-17 16:51:08 UTC
Interesting finds, Martin, thanks!
To your observations I'd like to add that fglrx also has problems calculating the DPI: when my external monitor is not attached, the login screen looks weird (text boxes for login/pass and the font inside them are too big). But at the same time, when I log in, KDE thinks my external monitor is attached (workspaces appear wide)
Comment 27 Egbert Eich 2008-07-21 03:23:04 UTC
@Martin: The issue is that one display reports a size the other one doesn't (possibly because you are referencing a display in OutputOrder which isn't present). So 96dpi is the fallback value. When changing the output order the info is taken from the other display.
@Konstantin: I have no clue any more why you are seeing a 'stretched out mode'.
I haven't seen this particular problem reported elsewhere. At least in any of the later drivers the hw scalers are fully programmed so I don't know what would scale the screen.
I've just pushed a patch which gives more verbose logging on the scaler settings.
Please retry with the latest driver and provide a -logverbose 7 log if the problem still persists.
Comment 28 Egbert Eich 2008-08-04 05:35:19 UTC
Luc, I'm running out of ideas here. Maybe you have another one.
Comment 29 Martin Nowack 2008-08-04 14:58:44 UTC
Created attachment 18108 [details]
logverbose 7 - without outputorder, without leftof
Comment 30 Martin Nowack 2008-08-04 15:01:16 UTC
Created attachment 18109 [details]
logverbose 7 - without outputorder, with leftof
Comment 31 Martin Nowack 2008-08-04 15:02:11 UTC
Created attachment 18110 [details]
logverbose 7 - with outputorder, without leftof
Comment 32 Martin Nowack 2008-08-04 15:02:57 UTC
Created attachment 18111 [details]
logverbose 7 - with outputorder, with leftof
Comment 33 Martin Nowack 2008-08-04 15:21:17 UTC
Ok, I tried to provide several setups maybe it helps to nail down the problem.
The attached logs are all combinations for with(out) outputorder and with(out) left-of.

My ideal setup would be if the external screen is left of the laptop panel and "primary" screen would be the laptop panel itself.

Without outputorder independent of leftof, initially the laptop panel is scaled.
With outputorder the laptop panel is not scaled but for the external screen the wrong resolution is picked up.

But there is a xrandr way to get the things right finally with outputorder=PANEL and VGA_1 left of the panel.

Following output after xrandr without arguments:

Screen 0: minimum 320 x 200, current 2800 x 1050, maximum 3080 x 1

PANEL connected 1400x1050+1400+0 287mm x 215mm
   1400x1050      60.0*+
   1680x1050Scaled   60.3
	...
VGA_1 connected 1280x1024+0+0 434mm x 270mm
   1680x1050      60.0 +
   1280x1024      75.0*    59.9
	...
DVI-D_1 disconnected

The strange thing is that VGA_1 has the wrong resolution but the more strange thing is the xpos of PANEL is 1400.

After:
xrandr --output VGA_1 --mode 1680x1050
Problem, left part of the PANEL screen is also on the right part of the VGA_1 screen.

Moving PANEL a little bit more right:
xrandr --output PANEL --pos 1680x0

Log out of kde and log in (without X restart)

It looks exactly as it should look like :)

Oh and it is last git commit: e65231ef
Comment 34 Konstantin Svist 2008-08-04 15:28:42 UTC
(In reply to comment #27)

Hi again,
sorry I haven't checked back on this bug for a while..
I've seen the updates in my email, but haven't really have time to install the driver and play around. I'll try to make some time for this soon.
Comment 35 Egbert Eich 2008-08-13 00:08:34 UTC
@Martin: Your problems are different from Konstantin's. Yours are not driver related. 
RandR picks your initial modes. It makes some decisions (attemting to take some configuration preferences into account) which don't seem to meet everybody's expectations. Now the question is: are there enough configuration options to nail down the setup sufficiently to meet the needs of each user. Probably not. 
xrandr tries to give you a two monitor (xinerama like) setup with two 1400x1050 screens side by side. Since your monitor doesn't provide the 1400x1050 resolution of your panel it falls back to one resolution lower. This is debatable but I suppose there are arguments both ways.
Have you checked the xorg.conf man page for all the available options for a monitor?
You can assign a monitor to a specific output, set the preferred mode and position.
RandR has really been created to make configuration dynamic and this seems to work for you.
Comment 36 Egbert Eich 2008-11-01 14:40:57 UTC
*** Bug 13605 has been marked as a duplicate of this bug. ***
Comment 37 Egbert Eich 2008-11-02 00:59:32 UTC
*** Bug 18344 has been marked as a duplicate of this bug. ***
Comment 38 Konstantin Svist 2008-11-20 13:39:24 UTC
Hi,
Sorry for taking so long but I finally found some time to try out the latest version of radeonhd driver (as usual, compiled from source as per instructions on http://www.x.org/wiki/radeonhd)

I'm still having the problem with external monitor resolution - this time the monitor reports resolution as 1680x1050 (which is the native) but the image is overscanned horizontally so everything looks stretched out and the sides disappear into the ether.

Interesting to note that xorg.0.log reports every entry for "EDID (in hex)" exactly the same:

(II) RADEONHD(0): EDID (in hex):
(II) RADEONHD(0):       00ffffffffffff005205d60766915029
(II) RADEONHD(0):       0110010308291a78ee60e5a3574b9c25
(II) RADEONHD(0):       115054bfef0031ca314a454a614c8180
(II) RADEONHD(0):       a940b3000101f00ad0b420e02d10126c
(II) RADEONHD(0):       a20098321100001e000000fe004c4344
(II) RADEONHD(0):       204d4f4e49544f520a00000000fd0037
(II) RADEONHD(0):       4c1e520e000a202020202020000000fc
(II) RADEONHD(0):       004c4344204d4f4e49544f52000000c7

Comment 39 Peter Hercek 2008-12-21 09:56:08 UTC
Created attachment 21359 [details]
Xorg.0.log showing radeonhd claiming support of 1400x1050 while the LCD is up to 1280x1024 only
Comment 40 Peter Hercek 2008-12-21 10:00:54 UTC
I think I have this bug too. I hope it is not randr "problem" as Martin had.
I have two LCDs.
The first one (which can handle resolutions up to 1400x1050) is connected to DVI-I_1/digital.
The second one (which can handle resolution up to (1280x1024) is connected to DVI-I_2/digital.
Radeonhd driver correctly recognizes the maximum resoulutions of the LCD when decoding EDID. This can be seen on lines 661 and 1179 of the attached Xorg.0.log file. But later on line 1547, radeonhd claims that mode 1400x1050 is supported on DVI-I_2/digital, which does not seem right to me. I would tell it is definitely a bug but I do not know the source code ... maybe there is something later which takes back the claim :)

(II) RADEONHD(0): FUNCTION: rhdRROutputModeValid
(II) RADEONHD(0): rhdRROutputModeValid: Output DVI-I_2/digital : 1400x1050
Modeline "1400x1050"  122.00  1400 1488 1640 1880  1050 1052 1064 1082 +hsync +vsync
(II) RADEONHD(0): FUNCTION: RHDRRModeFixup
(II) RADEONHD(0): FUNCTION: TMDSBModeValid
(II) RADEONHD(0): rhdRROutputModeValid: 1400x1050: Mode OK

At the user level this presents itself as "Out of range" message on my LCD connected to DVI-I_2/digital. Even "xrandr -q" reports mode 1400x1050 as supported on DVI-I_2/digital in this case and it is selected at X startup. The DVI-I_2/digital connected monitor can be made working by "xrandr --output DVI-I_2/digital --auto". So xrandr correctly recognizes that prefered mode on DVI-I_2/digital is 1280x1024. It is possible to make it working without manual xrandr fix by adding PreferedModes for both LCD monitors to xorg.conf file. It is not enough to add the PreferedMode for only one of the monitors.

Versions used: xorg-server-1.5.3, xorg-server-utils-7.4, xf86-video-radeonhd-git-20081221 (commit 003325a56684649171b2c1af50aa490b1461ee16). Xorg.0.log was attached. If you need more information, let me know.

Note: the bug was not there when I used xorg-server-1.4.2 and xf86-video-radeonhd-1.2.1.
Comment 41 Laurent Raufaste 2009-04-17 01:05:08 UTC
Hi,

I have the same problem.

I own an RV635 AT card with 2 LCD:
 - DELL E248WFP (1920*1200) (DVI)
 - DELL E197FP (1280*1024) (VGA)

Problem: When I start X, I get a 1280x1024 desktop in clone mode.
Everytime I need to setup the correct resolution with grandr.

Here's my xrandr -q output:
Screen 0: minimum 320 x 200, current 3200 x 1200, maximum 3200 x 1200
DVI-I_1/digital connected 1920x1200+0+0 518mm x 324mm
   1920x1200      60.0*+
   1600x1200      59.9  
   1280x1024      75.0     59.9  
   1152x864       74.9  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
DVI-I_1/analog disconnected
DVI-I_2/digital disconnected
DVI-I_2/analog connected 1280x1024+1920+0 380mm x 305mm
   1280x1024      60.0*+   75.0     59.9  
   1152x864       74.9  
   1024x768       75.1     60.0  
   800x600        75.0     60.3  
   640x480        75.0     60.0  
   720x400        70.1  
TV_7PIN_DIN disconnected


Here's my xorg.conf:
Section "Device"
        Identifier      "ATI Radeon HD 2400 Pro"
        Driver          "radeonhd"
        Option          "DVI-I_1/digital" "Dell E248WFP"
        Option          "DVI-I_2/analog" "Dell E197FP"
EndSection

Section "Monitor"
        Identifier      "Dell E248WFP"
        #Option         "PreferredMode" "1920x1200"
        #Option         "PreferredMode" "1920x1200+0+0"
EndSection

Section "Monitor"
        Identifier      "Dell E197FP"
        #Option         "PreferredMode" "1280x1024"
        #Option         "PreferredMode" "1280x1024+1920+0"
        Option          "RightOf" "Dell E248WFP"
EndSection

Section "Screen"
        Identifier              "Dual Screen"
        Device                  "ATI Radeon HD 2400 Pro"
        DefaultDepth    24
        SubSection              "Display"
                Virtual         3200 1200
        EndSubSection
EndSection

I'm using debian's radeonhd 1.2.5

Am I doing something wrong ?
Comment 42 Matthias Hopf 2009-04-17 06:40:11 UTC
I assume you tried the PreferredModes that are commented in your config.
What Xserver version are you using? Quite a number of versions used to have severe bugs in initial display placement.
Comment 43 Matthias Hopf 2009-04-17 06:41:27 UTC
Also please note that in this bug report I'm seeing approximately 5 different issues. It's not exactly helpful to have them all mangled up in one bug.
Comment 44 Laurent Raufaste 2009-04-17 07:08:50 UTC
(In reply to comment #42)
> I assume you tried the PreferredModes that are commented in your config.
> What Xserver version are you using? Quite a number of versions used to have
> severe bugs in initial display placement.
> 

Exactly, I tried a lot of things, including specifying some PreferredModes with no luck.

I'm using xorg-server 2:1.6.1-1 (buildd@excelsior.roeckx.be) (the one in debian unstable)

(In reply to comment #43)
> Also please note that in this bug report I'm seeing approximately 5 different
> issues. It's not exactly helpful to have them all mangled up in one bug.
> 

As I swa many other bugs similar to mine closed as duplicates, I thought it would be easier for you to post my experience here. Do you want me to open a new but report ?

Thanks =)
Comment 45 Matthias Hopf 2009-04-17 07:32:46 UTC
(In reply to comment #44)
> I'm using xorg-server 2:1.6.1-1 (buildd@excelsior.roeckx.be) (the one in debian
> unstable)

So 1.6.1 still has issues with preferred mode selection? Eek.

> (In reply to comment #43)
> As I swa many other bugs similar to mine closed as duplicates, I thought it
> would be easier for you to post my experience here. Do you want me to open a
> new but report ?

It's typically better to create a new one and let the bug owners decide which are duplicates. Except if you're absolutely sure that you found a duplicate.

In this case please create a new bug. It's possible that it's a duplicate, but not of this one.
Comment 46 Alec Habig 2009-04-17 07:47:40 UTC
I've an open bug on the way PreferredMode gets ignored, that has gotten zero love from the X folks, bug 16927.

What's the accepted way for developers and testers of one facet of X (us on the radeonhd list) to rattle the cages of people working on another part (xrandr, I think is the appropriate place)?
Comment 47 Alex Deucher 2009-04-17 07:53:53 UTC
(In reply to comment #46)
> I've an open bug on the way PreferredMode gets ignored, that has gotten zero
> love from the X folks, bug 16927.
> 
> What's the accepted way for developers and testers of one facet of X (us on the
> radeonhd list) to rattle the cages of people working on another part (xrandr, I
> think is the appropriate place)?
> 

Are you sure this isn't specific to radeonhd?  Have you test with any other drivers?
Comment 48 Alec Habig 2009-04-17 08:02:56 UTC
I don't know for sure that it's not radeonhd, other than that it started as radeonhd bug 16740, in which Egbert fixed some driver stuff and suggested punting the rest to xrandr.  And none of the xrandr people have chimed in at all one way or the other.

I don't have the hardware to test it on a different card, unfortunately.
Comment 49 Matthias Hopf 2009-04-17 08:11:49 UTC
(In reply to comment #46)
> What's the accepted way for developers and testers of one facet of X (us on the
> radeonhd list) to rattle the cages of people working on another part (xrandr, I
> think is the appropriate place)?

*Theoretically* you have done everything you can. Sometimes an additional mail on the xorg mailing list helps.

*Theoretically* we (explicitly including me) could / should work on that bug as well (as I do have quite some RandR experience).


Practically the day has only 24h and at the moment we're completely swamped at SuSE. To the best of my knowledge the other X.org developers are in a similar situation, though hopefully not as extreme.
Comment 50 Konstantin Svist 2009-09-09 16:34:35 UTC
Update:
I have installed Fedora 11 with working xrandr and more-or-less-working radeon driver. After running into the same bad-resolution problem, I've played around with some settings. Finally, I found one that works (calculated at http://www.arachnoid.com/modelines/)

# 1680x1050 @ 60.10 Hz (GTF) hsync: 65.33 kHz; pclk: 147.38 MHz
Modeline "1680x1050_60.10" 147.38 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync

I think this is what Winders and fglrx used, at least according to the clock reading on the OSD

On a whim, I tried a 60.0Hz version and it worked too
# 1680x1050 @ 60.00 Hz (GTF) hsync: 65.22 kHz; pclk: 147.14 MHz
Modeline "1680x1050_60.00" 147.14 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync

65Hz didn't work and I gave up interest after that.
Comment 51 Konstantin Svist 2009-09-09 16:41:29 UTC
Created attachment 29358 [details] [review]
Xorg.0.log with EDID of quirky monitor

Attaching my Xorg.0.log
VGA-0 is the monitor with bad EDID, the modes in my previous comment apply to it.
Comment 52 Konstantin Svist 2009-12-02 14:48:56 UTC
Update: no longer works in Fedora 12
Monitor reports signal out of range or signal disconnected


(II) LoadModule: "radeon"
(II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
(II) Module radeon: vendor="X.Org Foundation"
        compiled for 1.7.1, module version = 6.12.99
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 6.0

Found a "probed" mode:
(II) RADEON(0): Modeline "1680x1050"x0.0  146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync (65.3 kHz)
(II) RADEON(0): Not using mode "1680x1050" (bad mode clock/interlace/doublescan)

When used, it shows flickering 1600x1080 resolution (according to the monitor OSD)
Comment 53 Konstantin Svist 2010-03-08 12:50:36 UTC
I've updated Fedora to a fresh kernel and the problem disappeared.
I've also switched off KMS to work around a nasty corruption bug and turned on mesa-dri-drivers-experimental. These might've had an effect too...

current versions:
kernel: 2.6.32.9-67.fc12.i686
xorg-x11-drv-radeonhd: 1.3.0-4.2.20091204git.fc12
mesa-dri-drivers-experimental: 7.7-3.fc12

working modes:
xrandr --newmode 1680x1050k 147.38 1680 1784 1968 2256 1050 1051 1054 1087 -HSync +Vsync
xrandr --newmode 1680x1050l 146.25  1680 1784 1960 2240  1050 1053 1059 1089 -hsync +vsync
Comment 54 Konstantin Svist 2010-06-28 10:20:06 UTC
Keeps working with xrandr workaround script.
Will this ever get fixed?
Comment 55 Konstantin Svist 2010-06-28 10:20:22 UTC
Keeps working in Fedora 13 with xrandr workaround script.
Will this ever get fixed?
Comment 56 Jeremy Huddleston 2011-10-16 15:57:56 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 57 Konstantin Svist 2011-10-16 17:09:32 UTC
Yes, it applies to ati driver in exactly the same way
So far the workarounds that work are video=1680x1050 in kernel command line to get full resolution in VTs, and xrandr modes from comment 53 for X11
Comment 58 Alex Deucher 2011-10-17 07:16:19 UTC
(In reply to comment #57)
> Yes, it applies to ati driver in exactly the same way
> So far the workarounds that work are video=1680x1050 in kernel command line to
> get full resolution in VTs, and xrandr modes from comment 53 for X11

It would probably be best to open a new bug for KMS.  There are already too many intermixed issues here.  Please attach your xorg log and dmesg output to the new bug.