[virt-tools-list] virt-viewer: Having per window full-screen state causes monitor arrangement issues

Jonathon Jongsma jjongsma at redhat.com
Mon Sep 30 19:02:45 UTC 2013

----- Original Message -----
> From: "Hans de Goede" <hdegoede at redhat.com>
> To: "Marc-André Lureau" <mlureau at redhat.com>
> Cc: "Virt Tools" <virt-tools-list at redhat.com>
> Sent: Friday, September 20, 2013 9:47:09 AM
> Subject: Re: [virt-tools-list] virt-viewer: Having per window full-screen state causes monitor arrangement issues
> Hi,
> On 09/20/2013 04:22 PM, Marc-André Lureau wrote:
> <snip>
> >> For now I would stick with what I've suggested, so keep the current
> >> ltr auto-align, while adding code to make sure we update coordinates
> >> whenever necessary + use physical monitor coordinates in the all
> >> monitors full-screen case.
> >
> > I think it's equally bad (if not worse) that monitors are "swaped" whether
> > they are all in fullscreen or not (in your example) (you will get your
> > startmenu/taskbar jumping from window/monitor)
> They won't get swapped, the current auto-ltr align code already puts
> windows in the ltr order they are in on the client machine.

This is only partially true.  The auto-ltr alignment code puts windows in the ltr order that they *were in on the client machine at the point when each window was last resized*.  If you then move this window to a different point on the screen, that new position is not used to determine how to arrange the monitors *until it is resized*.  And actually, even this is a bit of a lie.  In reality, it uses the last *adjusted* position at the time of resizing to calculate alignment.

Consider the following situation:

Display A is a 400x400 window at (100, 100)
Display B is a 400x400 window at (800, 200)

The auto-alignment algorithm will place these two displays as follows:
 - A -> 400x400 @ (0, 0)
 - B -> 400x400 @ (400, 0)

So far, so good: the displays are aligned in the expected order with no gap between them.  Now, let's say that we swap the arrangement of these windows so that display B is to the left of A.  Specifically:

Display B is a 400x400 window at (100, 100)
Display A is a 400X400 window at (800, 200)

Nothing changes when we move the windows on the client, which is as it should be (we wouldn't want the displays to get re-arranged simply by dragging a window around). 

But now let's say that we resize Display B to be 600x600.  Since Window A was not resized, its position will not be updated at all.  So when the auto-align algorithm runs, it will try to lay out these windows left-to-right but it will use the position (100, 100) for window B and the position (0, 0) for window A (which is the adjusted position at the time of the last resize of window A).  It will calculate that window A (0, 0) is closer to the origin than window B (100, 100) is, which results in the following auto-aligned layout:
 - A -> 400x400 @ (0, 0)
 - B -> 600x600 @ (400, 0)

Clearly not quite what we want, since Window B is actually to the left of Window A on the client. But the alignment in the guest is such that Display A is to the left of Display B.

So regardless of whether display swapping happens during fullscreen/un-fullscreen or not, we need to find a much smarter method of alignment for multiple displays.

> So if you have disp1 and disp2 in the guest, and you've disp2 on
> the left monitor of your client machine and disp1 right, then the
> auto-align code will already put disp2 first in the ltr ordering (*).
> So if you then fullscreen both no swapping will happen.
> Regards,
> Hans
> *) Or at least that is how it used to be, it seems that this is broken
> now too.
> _______________________________________________
> virt-tools-list mailing list
> virt-tools-list at redhat.com
> https://www.redhat.com/mailman/listinfo/virt-tools-list

More information about the virt-tools-list mailing list