I'm using a two-monitor setup with an ATI Mobility Radeon HD 4200 graphics card on my Compaq Presario CQ61. The Laptop screen has a hardware resolution of 1366x768, the external monitor a hardware resolution of 1280x1024. If I set up the second monitor using xrandr --output VGA-0 --mode 1280x1024 --pos 1368x0 --rotate normal --output LVDS --mode 1366x768 --pos 0x0 --rotate normal (or the gnome gui, the effects are equal) I expect: 1) the left 1366x768 area to be on the laptop screen, and 2) the right 1280x1024 area to be on the big monitor. But I observe: 1) happens as expected 2) happens almost. Instead, the 2 rightmost pixels on the laptop monitor are repeated on the left border of the big monitor and the two rightmost columns of the right monitor are not visible on any monitor at all. If I switch the laptop monitor resolution to 1280x720 (or any more "common" resolution), this effect does not occur and everything works as expected. Build Date & Platform: X.Org X Server 1.12.4 Release Date: 2012-08-27 [ 52.070] X Protocol Version 11, Revision 0 [ 52.070] Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian [ 52.070] Current Operating System: Linux eva 3.2.0-4-486 #1 Debian 3.2.32-1 i686 [ 52.070] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-486 root=UUID=001323c2-d51c-4188-8cf7-153dc486a5c8 ro quiet [ 52.070] Build Date: 05 November 2012 10:28:15AM [ 52.070] xorg-server 2:1.12.4-3 (Julien Cristau <jcristau@debian.org>) OS: Linux Mint Debian Update Pack 6 Other: This bug was also reported on a Ubuntu tracker (I copied it and edited to suit my circumstances), but it has been reported on multiple OS's and it would appear to be an upstream Xorg bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/680614 There is a workaround in the form of "xrandr --output VGA-0 --auto --pos 1368x0" (shift the second display 2 pixels to the right).
> xrandr --output VGA-0 --mode 1280x1024 --pos 1368x0 --rotate normal --output > LVDS --mode 1366x768 --pos 0x0 --rotate normal [...] > There is a workaround in the form of "xrandr --output VGA-0 --auto --pos > 1368x0" (shift the second display 2 pixels to the right). I assume the first '--pos 1368x0' is a typo and should be '--pos 1366x0'. I'm afraid this is not easily fixable, as the hardware only supports horizontal offsets which are a multiple of 4, so the drivers just round down values that aren't.
As Michel noted, this is a hardware limitation. To fix this properly, the xserver would need to be changed to allocate separate buffers for each display rather than one big surface for all displays. Unfortunately, this is a fairly major task.
Thank you Alex T. for opening this bug, and Michel and Alex D. for your feedbacks. Does the hardware limitation (horizontal offsets multiple of 4) apply to all three of the popular desktop graphics hardware Intel, ATI/AMD/Radeon and Nvidia, or only to a subset of these? (Please excuse my ignorance if this is a stupid question :-)
(In reply to comment #3) > Thank you Alex T. for opening this bug, and Michel and Alex D. for your > feedbacks. > > Does the hardware limitation (horizontal offsets multiple of 4) apply to all > three > of the popular desktop graphics hardware Intel, ATI/AMD/Radeon and Nvidia, > or only > to a subset of these? (Please excuse my ignorance if this is a stupid > question :-) Vertical alignments have to a multiple of 2 as well. It applies to most Radeon asics. Not sure about other vendors, but it's likely they may have similar requirements.
So does the proprietary fglrx driver include a hack/workaround for this? Because with fglrx the position of the second screen is correct!
For me the problem exists only when the configuration sets the 1920x1080 monitor is on the rightside of the 1366x786 one, but not vice versa.
(In reply to comment #6) > For me the problem exists only when the configuration sets the 1920x1080 > monitor is on the rightside of the 1366x786 one, but not vice versa. See comment 1. 1366 is not a mutliple of 4 while 1920 is. IIRC, vesa mandates the the hdisplay value be a multiple of 8, so 1366 is technically not vesa compliant.
Yeah, but why is this only when the 1920 monitor is right of 1366 and not when 1920 ist left of the 1366 one? And why does the fglrx driver work fine?
Created attachment 90633 [details] [review] possible fix Does this patch fix the issue?
Created attachment 90665 [details] applied patch failed No, it doesn't. It messed it all up, as you can see in the attached picture. The patch was applied on 3.13rc3 on a Ubuntu saucy 64bit. The configuration included a common bottomline of each display. The 1366 monitor was the left one (notebook). A configuration with only one display worked, so the patch didn't effect that.
AH: As per your comment #8 about it only being a problem when the 1920 is on the right of the 1366 monitor - this makes sense.... What happens is that something doesn't expect offsets that aren't multiples of 8. When you have the 1920-1366 you end up with the 1920 starting at X=0, and the 1366 starting at X=1920 (which is divisible by 8) - so everything is happy. When you have the 1366-1920 setup you end up with the 1366 starting at X=0, and the 1920 starting at X=1366 and having a display not aligned to /8 value gets the thing confused.
*** This bug has been marked as a duplicate of bug 58652 ***
Thanks for the explanation. It's a pity that it's no possible to solve this bug, yet. It's the last feature I need after DPM and UVD have been included in the oss radeon-driver.
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.