Red Hat Bugzilla – Bug 480633
KMS:RV530:X1600 xrandr/xorg with dual head places and sizes physical monitor incorrectly
Last modified: 2011-06-27 10:05:33 EDT
Created attachment 329352 [details] xorg.0.log Description of problem: Using xorg Radeon driver on a X1600 (RV530) Using xrandr for a dual head setup with one CRT and one LCD screen with different physical sizes and resolutions. Xrandr reports that the monitors are adjacent: CRT, 1152x864, on left. xandr reports: VGA-0 connected 1152x864+0+0 LCD, 1280x720, on right, aligned with bottom of VGA-0. xrandr reports: DVI-0 connected 1280x720+1152+144 However, the LCD monitor, while at the correct resolution, does not show the whole of its portion of the X screen. There is about a 100px gap between the visible edges of the screens and around the LCD such that the edges of maximised windows on this screen disappear. If I manually resize a window to fill the visible LCD screen then the preview in the desktop switcher shows a gap around the edges of that window and a maximised window on the adjacent CRT. The displayed origin of the LCD screen seems to be about 1060x148. The bottom edge of the display is positioned correctly. Gnome panels dock to the top and bottom of the display although the ends disappear off (ie they align correctly with what X thinks is the edge of the display but not what is actually displayed). The CRT display suffers no such problems, possibly due to it being at the origin of the x screen, or being the primary display. There is no way as I can see it to tell X to regard the LCD as the primary display. I believe this problem is due to the fact that the 2 displays have different dot pitches. However, setting DisplaySize in xorg.conf has no effect on this problem. Indeed, using a value of DisplaySize for the LCD calculated to give a DPI equal to that of the CRT has no effect on what is displayed. Additionally, xorg will only report the manually set DisplaySize correctly if IgnoreEDID and NoDDC are set in xorg.conf. This does not fix the display problem though, and causes xrandr to report a display size of 0mm x 0mm. On a related note, GDM has too large fonts, probably also due to incorrect DPI calculation with this setup. Once logged in to a session font sizes are rendered correctly. The CRT is a Dell E771p which gives correct EDID and DDC info. The LCD is a Digimate L-1523 which appears to give false EDID and DDC info and needs a custom modeline to display at its native 1280x720 (funnily enough this monitor worked fine with windows xp although it was used as a single head on that machine.) The actual physical sizes of the screens are those given in my xorg.conf Output of xrandr: Screen 0: minimum 320 x 200, current 2432 x 864, maximum 3968 x 1400 VGA-0 connected 1152x864+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1152x864 75.0*+ 1400x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 85.0 75.0 70.1 60.0 832x624 74.6 800x600 85.1 72.2 75.0 60.3 56.2 640x480 85.0 72.8 75.0 59.9 720x400 85.0 640x400 85.1 640x350 85.1 DVI-0 connected 1280x720+1152+144 (normal left inverted right x axis y axis) 0mm x 0mm 1280x720 60.0*+ 1280x960 60.0 1024x768 60.0 800x600 60.3 56.2 640x480 59.9 Xorg.0.log attached. xorg.conf to follow. Version-Release number of selected component (if applicable): xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64 xorg-x11-drv-ati-6.9.0-63.fc10.x86_64 How reproducible: Always. Steps to Reproduce: 1. Use the setup detailed above 2. 3. Actual results: Display does not show the whole of its assigned portion of the X screen. Expected results: Display shows all that it should. Maximised windows do not lose their edges off the screen. Windows do not need to be manually moved or resized to make all their contents readable. All is happy and well. Additional info: The xorg.conf attached gives a stable dual head setup that works apart from this problem. Several hours were spent with google and man pages finding the various options. As usual with linux, I now know too much about something that ought to Just Work. If I knew how to actually write code then I would patch this myself but I'm afraid I don't!
Created attachment 329353 [details] xorg.conf
Created attachment 329354 [details] screenshot showing windows filling the visible displays The window on the right has been manually resized to fill the right-hand display (apart from the area filled by the panel at the top which on the display is missing its top few pixels). Note the space to the left and right of the window. The window on the left is maximised and correctly fills the space on the left hand display.
Created attachment 329355 [details] screenshot showing maximised window outside visible area In this screenshot the right-hand window is maximised. The red line shows the area that I can actually see.
I've just realised that the viewable area on the right-hand display is 1152 "pixels" wide - the same width as the left-hand display. However, it's 716 "pixels" high. The display is actually being driven at 1280x720.
This is still an issue with F12 Beta. One display (left) is 1280x1024, the LCD (right) is 1280x720. xrandr/xorg thinks the displays' edges are touching, however, there is a non-visible area of the screen in between the two displays. Using xrandr to set fbmm, fb or dpi has no effect on this issue. $ xrandr --prop Screen 0: minimum 320 x 200, current 2560 x 1024, maximum 3200 x 1280 VGA-0 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 300mm x 225mm EDID: 00ffffffffffff0010ac02704e453842 310a0103081e17bbeae5b89e594a9c26 10484ca4420061594559315981800101 010101010101c31e0020410020301060 13002ce110000018000000ff00353152 4e483043344238454e0a000000fc0044 454c4c202045373731700a20000000fd 0032a01e460b000a202020202020005d load_detection: 1 (0x00000001) range: (0,1) 1280x1024 60.0*+ 1024x768 75.0 + 85.0 75.0 800x600 85.1 75.0 640x480 85.0 75.0 59.9 720x400 70.1 DVI-0 connected 1280x720+1280+304 (normal left inverted right x axis y axis) 338mm x 270mm EDID: 00ffffffffffff003aac010001000000 200c010308221b00ca0b329c5a4d8c26 204e57afcf0081800101010101010101 010101010101302a009851002a403070 1300520e1100001e000000fe000a2020 20202020202020202020000000fe000a 202020202020202020202020000000fc 000a20202020202020202020202000d6 dvi_monitor_type: analog scaler: center coherent_mode: 1 (0x00000001) range: (0,1) load_detection: 1 (0x00000001) range: (0,1) 1280x720 60.0*+ 1024x768 60.0 800x600 60.3 56.2 640x480 59.9
The DisplaySize set in xorg.conf is ignored (compare with xrandr prop above): $ cat /etc/X11/xorg.conf # xorg.conf for spanning dual monitors with xrandr # DGM L-11523 on DVI-0 # Dell E771p on VGA-0 # Section "ServerFlags" Option "AIGLX" "on" Option "DontZap" "false" EndSection Section "Monitor" # 1280x720 @ 60Hz, 44.58 kHz hsync Identifier "Monitor0" ModelName "DGM L-1523" HorizSync 28.0 - 60.0 VertRefresh 43.0 - 60.0 Option "DPMS" "on" Modeline "1280x720" 66.70 1280 1304 1376 1496 720 722 724 743 Option "Position" "1280 304" DisplaySize 330 208 Option "PreferredMode" "1280x720" EndSection Section "Monitor" Identifier "Monitor1" ModelName "Dell E771p" DisplaySize 328 246 HorizSync 30.0 - 70.0 VertRefresh 50.0 - 160.0 Option "DPMS" "on" ModeLine "1280x1024" 108.0 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync Option "PreferredMode" "1280x1024" EndSection Section "Device" #this might only work with radeon driver Identifier "ATI0" Driver "radeon" Option "DRI" "On" Option "AccelMethod" "EXA" Option "Monitor-VGA-0" "Monitor1" Option "Monitor-DVI-0" "Monitor0" BusID "PCI:2:0:0" EndSection Section "DRI" Mode 0666 EndSection Section "Extensions" Option "Composite" "Enable" EndSection
John is KMS enabled ? Please also attach full dmesg and new xorg log of Fedora 12. Are the screenshot still representative of the issue ?
Created attachment 369401 [details] dmesg
Created attachment 369402 [details] Current Xorg.0.log
Hi. The screen shots are still representative. I'm booting with KMS disabled as more often than not the system hangs on boot with KMS on, but even with KMS on the problem is still apparent. I think this issue is related to the mode of the LCD panel. I had to write a modeline to get 1280x720 as otherwise I can only get 1024x768, 800x600 and 640x480, all of which have the wrong aspect ratio for the display. It seems that the monitor's EDID is either wrong or being wrongly parsed by the driver. Interestingly, Windows XP picks up the correct mode, so perhaps the manufacturer's doing something non-standard. With the default mode of 1024x768, there is no missing screen between the two displays and everything functions as I would expect. I tested with no xorg.conf and all was fine, apart from not having the 1280x720 mode. So this bug only appears when using the 1280x720 mode from my modeline. The modeline drives the monitor perfectly, so the hardware side seems OK. I'm attaching xorg.0.log and dmesg output for the bug case.
Please provide dmesg with KMS enabled, we are focussing on fixing KMS, also provide Xorg log with KMS on.
Created attachment 369664 [details] dmesg with KMS enabled
Created attachment 369665 [details] Xorg log with KMS enabled
Logs provided as requested. (Enabling or disabling KMS has no effect on this bug).
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Bug still exhibits in F13. I'm upgrading to F14 soon, so will test then.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.