| Summary: | Position of second monitor wrong in dual monitor setup if first monitor is 1366x768 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | grumpyrogue | ||||||
| Component: | Driver/Radeon | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | low | CC: | hill-robert | ||||||
| Version: | 7.7 (2012.06) | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux (All) | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Attachments: |
|
||||||||
|
Description
grumpyrogue
2013-04-25 02:16:18 UTC
> 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.