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
Created attachment 14316 [details] Xorg.0.log
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?
(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
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?
(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
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.
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.
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?
Ummm... am I supposed to reassign the bug back to previous person?
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.
Created attachment 15011 [details] patch + logverbose -7
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)]
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")
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.
(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?
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.
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
(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 :)
Created attachment 15585 [details] logverbose 7 - 3rd try Okay, I think it's the right one this time :)
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.
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
(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.
Created attachment 15666 [details] logverbose 7 - 5th try Here you go. I didn't notice any differences
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.
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.
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)
@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.
Luc, I'm running out of ideas here. Maybe you have another one.
Created attachment 18108 [details] logverbose 7 - without outputorder, without leftof
Created attachment 18109 [details] logverbose 7 - without outputorder, with leftof
Created attachment 18110 [details] logverbose 7 - with outputorder, without leftof
Created attachment 18111 [details] logverbose 7 - with outputorder, with leftof
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
(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.
@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.
*** Bug 13605 has been marked as a duplicate of this bug. ***
*** Bug 18344 has been marked as a duplicate of this bug. ***
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
Created attachment 21359 [details] Xorg.0.log showing radeonhd claiming support of 1400x1050 while the LCD is up to 1280x1024 only
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.
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 ?
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.
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.
(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 =)
(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.
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)?
(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?
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.
(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.
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.
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.
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)
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
Keeps working with xrandr workaround script. Will this ever get fixed?
Keeps working in Fedora 13 with xrandr workaround script. Will this ever get fixed?
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.
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
(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.
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
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.