Comment # 20 on bug 1054645 from rens groenewegen

handling correctly configurations like:
1 2 3 4

1 2 3
4

1 2
3 4

would be a start :-)

but there is folks who have this:

1 2 3
    4
(In reply to rens groenewegen from comment #16)
> 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...