Code review comment for lp:~alan-griffiths/mir/fix-1516670

Note that following scenario is still not working for me (but I am not sure if this MP was supposed to fix this):

Internal monitor 1280x800
External monitor 1920x1080

In different shells:
$ sudo bin/mir_demo_server --arw-file -f /tmp/mir_host
$ bin/mir_demo_server --host-socket /tmp/mir_host -f /tmp/mir_nested --vt 1
$ bin/mir_demo_client_display_config -m /tmp/mir_nested

Should start in clone mode, press 'h', press 'c' again. After last 'c' we should expect to go back to the original setup but we get into a strange setup instead. There seem to be two "framebuffer" surfaces, the first sized for the internal screen and the second for the external. On the external screen the two FB surfaces overlap, with the internal one being in front and hiding the top left part of the external. The client surface is only drawn on the external FB surface.

Also note that both the old and the new code don't handle properly cases where one output doesn't fully contain the other (e.g. 100x100+0+0 100x100+50+50). It's not a common case but we should (eventually) either support it or explicitly prohibit it.

> area.intersection_with(output.extents()))

Since area is the bounding rectangle of all outputs, isn't this expression equivalent to just output.extents()?

@Andreas
> hm I think this is an improvement but in clone mode we should use the smallest screen size
> for each surface and have the output scale.
...
> It should figure out a suitable intersection and try to select suitable modes on each output,
> instead of just aligning top_left.

Fair enough, we should probably rename the current clone policy to '(max)overlap' and implement a new 'clone' one. In any case there are both valid policies and should be properly supported. Plus there are cases where we can't 'clone' because there aren't any matching modes, so we need to fall back to 'overlap' anyway.