Thanks for reporting, I believe this likely is a virt-viewer issue, changing component.

This is mostly by design, to be somehow similar with current multi-device behaviour: when closing a window, you don't remove the device or disconnect the screen, The display are still there, it's not dynamic.

I am not sure what you ask for is the best thing to do. When closing the window, it could:

1. close the display immediately (not the same as multi-device)
2. close the display when layout configuration change (what we have now)
3. keep the display open

Can you make a rationale why 2 isn't a good compromise? Why should the Xrandr display be disconnected immediately when window is closed?

Depending on what we want, I see 1. or 3. as equally interesting options. I tend to prefer 3, since that's what multi-device does: it doesn't disconnect.

But with 3, how do we disconnect the monitor?

In all cases, it should be trivial to change the behaviour.

You've got great points.

I didn't know that this behaviour was intentional and closing the displays in 3. would be indeed a problem, the only reasonable way of dealing with it is that going through View -> And unchecking a display would disconnect it, whereas just closing it would keep it connected. But this is counter-intuitive. 

I suppose you can keep it at 2.

-- however there *is* a bug -- when second display gets closed and the window resizes, the display gets connected and open again, instead of being disconnected. So it doesn't work as expected anyway.

(In reply to comment #4)
> -- however there *is* a bug -- when second display gets closed and the
> window resizes, the display gets connected and open again, instead of being
> disconnected. So it doesn't work as expected anyway.

what is your vdagent version? We changed the way display resolution is switched with latest build, give it a try (only in brew iirc)

if you mean spice-vdagent-0.12.0-3.el6 (which is the latest one on brew), then it's happening on it as well.

(In reply to comment #3)
> This is mostly by design, to be somehow similar with current multi-device
> behaviour: when closing a window, you don't remove the device or disconnect
> the screen, The display are still there, it's not dynamic.
> 
> I am not sure what you ask for is the best thing to do. When closing the
> window, it could:
> 
> 1. close the display immediately (not the same as multi-device)

I would like to argue that this is the best perspective from a user pov, otherwise he can drag
windows off-screen without them showing up on another screen, also if there windows there,
if the display gets disabled, then the guest will move the windows to another screen, rather
then them becoming completely hidden.

So IMHO this is the better behavior, and easiest to implement in a consistent way too.

I realize this is a change compared to the multi qxl device setup, so lets just keep the
same behavior there, this way old vms will stay working as is (principle of least surprise)
while new vms get the new and improved behavior.

Regards,

Hans

I tend to agree with Hans. 2nd solution from comment 3 is the most counter-intuitive one IMO because window resize operations get increasingly more common (just move the window to the upper edge in gnome-shell or Windows 7) so there is no real persistence anyway. Personally, current behaviour of Windows VMs should match 3. but given that spicec was never able to close just one window and Windows version of r-v is affected by bug 871573, there is no real compatibility to keep up.

In addition good window managers can cope with monitors connecting/disconnecting quite nicely, rearranging windows to original layout if previously available monitor is reconnected.

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This bug has both an agent component and a remote-viewer / spice-gtk component. The agent component is related to bug 888821, and will be fixes as part of the fix for that. This bug will be used to track the remote-viewer / spice-gtk component.

I've just posted a patch upstream fixing this:
http://lists.freedesktop.org/archives/spice-devel/2013-January/011970.html

Moving to post.

The fix for this lives in spice-gtk, updating component.

Fixed in spice-gtk-0.14-7.el6 moving to modified.

Hi Hans, 

I've tried the latest builds of spice-gtk and vdagent. And even though the behaviour has changed, I'm not sure, it's the way we want it to be. 

Reopening of closed display has been fixed, one different issue has surfaced:
  -- for some reason the client always tries to establish connection on first n available displays, where n is number of windows open. Which results in: 
     -- user being unable to open displays out of order (e.g. instead of having displays 1, 3 and 4; he gets 1, 2, 3)
        -- this might be considered as OK, but remote viewer actually states it's waiting for the selected display and ends up with the wrong one. 
        -- the bigger issue related to this behaviour is: 
           -- user has no control of which display actually gets closed, when he closes a window.
              -- when user closes a window, then after a short period of time, the configuration alters in this way: It closes the highest open display, and maintains the first n displays open. Example for a use case, where this is wrong: 
user opened displays 1, 2, 3. Works mostly on displays 1,3, decides to close 2. After a short timeout, display 3 gets closed, 2 reopened, and work from 3 gets rearranged between 1 and 2. The expected way is obviously keeping 1, 3 open, closing 2. 

What do you think about it? Right now I don't believe it should be changed to verified.

(In reply to comment #18)
Hi,

> I've tried the latest builds of spice-gtk and vdagent. And even though the
> behaviour has changed, I'm not sure, it's the way we want it to be. 
> 
> Reopening of closed display has been fixed, one different issue has surfaced:
>   -- for some reason the client always tries to establish connection on
> first n available displays, where n is number of windows open. Which results
> in: 
>      -- user being unable to open displays out of order (e.g. instead of
> having displays 1, 3 and 4; he gets 1, 2, 3)
>         -- this might be considered as OK, but remote viewer actually states
> it's waiting for the selected display and ends up with the wrong one. 
>         -- the bigger issue related to this behaviour is: 
>            -- user has no control of which display actually gets closed,
> when he closes a window.
>               -- when user closes a window, then after a short period of
> time, the configuration alters in this way: It closes the highest open
> display, and maintains the first n displays open. Example for a use case,
> where this is wrong: 
> user opened displays 1, 2, 3. Works mostly on displays 1,3, decides to close
> 2. After a short timeout, display 3 gets closed, 2 reopened, and work from 3
> gets rearranged between 1 and 2. The expected way is obviously keeping 1, 3
> open, closing 2. 

You're right and this is rather unfortunate behavior. The problem is that currently the
guest-agent  expects a monitor-config message from the guest to have a continuous monitor range for monitors 1 - x, so if there are 3 monitors numbered 1 - 3 and you disable 2, it is impossible to send a sparse monitor config to tell the guest-agent to disable 2 and keep 1 and 3.

Fixing this requires changing the agent protocol to allow sparse monitor configs, + an agent capability bit to signal this is supported + agent + spice-gtk changes.

> 
> What do you think about it? Right now I don't believe it should be changed
> to verified.

I believe this is a different issue, and thus a new bug should be filed for it. The issue of remote-viewer
delaying re-configuring the monitors when a window is closed is resolved.

Note that that new bug likely will not get fixed for 6.4, since the fix although straight forward involves quite a bit of work.

Regards,

Hans

(In reply to comment #20)
> You're right and this is rather unfortunate behavior. The problem is that currently
> the guest-agent  expects a monitor-config message from the guest to have a
> continuous monitor range for monitors 1 - x, so if there are 3 monitors
> numbered 1 - 3 and you disable 2, it is impossible to send a sparse monitor
> config to tell the guest-agent to disable 2 and keep 1 and 3.
> 
> Fixing this requires changing the agent protocol to allow sparse monitor
> configs, + an agent capability bit to signal this is supported + agent +
> spice-gtk changes.

For people who are interested in this, this is now being tracked in bug 894036.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0343.html