http://bugzilla.novell.com/show_bug.cgi?id=1054645
http://bugzilla.novell.com/show_bug.cgi?id=1054645#c20
--- Comment #20 from rens groenewegen
tested with option --left-of, as stefan suggested.
starting point: 3 monitors. +---------+------------+ | hdmi-1 | hdmi-2 | 1920x1080 (both) | | | +---------+------------+ | | 2560x1440 | edp-1 | +_________+
xrandr --output HDMI-1 --scale 0.8x0.8 --left-of HDMI-2 X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 140 (RANDR) Minor opcode of failed request: 7 (RRSetScreenSize) Serial number of failed request: 37 Current serial number in output stream: 39 4.4.120-45-default:itsme:[/data/itsme] = xrandr |grep -e Screen -e connected Screen 0: minimum 320 x 200, current 3856 x 1944, maximum 8192 x 8192 eDP-1 connected 1536x864+0+1080 (normal left inverted right x axis y axis) 294mm x 165mm DP-1 disconnected (normal left inverted right x axis y axis) HDMI-1 connected primary 1536x864+384+0 (normal left inverted right x axis y axis) 527mm x 296mm HDMI-2 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 527mm x 296mm
screen buffer is wrong: should be 3456x1944 ( 1536 + 1920 )x 1944
output HDMI-2 should be at 1536x0, which it is not. it's at it's old position.
so much for what xrandr says. the FB operation fails, but the placement succeeds, although X has lost track of the reality "on the ground". check out the attachment with the screenshot (taken with a camera, not with X :-) ) of this text, on the gap between HDMI-1 and 2: there is no gap. while there should have been a 384 pixel gap.
as we can see, the word "have" in the previous sentence is not missing a single digit, not quite possible when 384 pixel should have been missing....
just contemplating these results: Order is important: screenbuffer size shrinking (width AND/OR height) can only be done *after* resizing outputs (the current outputs would generate an error, I think that is what happened here) screenbuffer size increasing (width AND/OR height) must of course happen *before* any output resizing. perhaps that has something to do with xrandr loosing track of actual placement... -- You are receiving this mail because: You are on the CC list for the bug.