Bug 881072 - Closing remote-viewer windows doesn't disconnect the display immediately
Summary: Closing remote-viewer windows doesn't disconnect the display immediately
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk
Version: 6.4
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Hans de Goede
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 888821
Blocks: 895654
TreeView+ depends on / blocked
 
Reported: 2012-11-28 15:07 UTC by Tomas Jamrisko
Modified: 2013-07-03 12:15 UTC (History)
14 users (show)

Fixed In Version: spice-gtk-0.14-7.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-21 08:49:26 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0343 normal SHIPPED_LIVE spice-gtk bug fix and enhancement update 2013-02-20 20:53:54 UTC

Description Tomas Jamrisko 2012-11-28 15:07:54 UTC
Description of problem:
Closing connection to a display doesn't disconnect (as reported by xrandr) until one of the remaining windows gets modified (resized).

This sometimes causes the previously closed window to be opened again without user's intention, 

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-16.el6.x86_64
xorg-x11-drv-qxl-0.1.0-2.el6
spice-vdagent-0.12.0-3.el6

How reproducible:
Always

Steps to Reproduce:
1. Just to make sure -- get 2 physical monitors on your client
2. Connect to your RHEL6.4 VM
3. Open a second monitor of your VM (View -> Displays -> ... )
4. Close the Display
5. Check xrandr (gnome display properties)
  
Actual results:
The display is still reported as connected

Expected results:
it should be disconnected

Additional info:
Resizing the only open window results in expected behaviour

Comment 2 Hans de Goede 2012-11-28 19:56:26 UTC
Thanks for reporting, I believe this likely is a virt-viewer issue, changing component.

Comment 3 Marc-Andre Lureau 2012-11-29 00:11:52 UTC
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.

Comment 4 Tomas Jamrisko 2012-11-29 09:07:57 UTC
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.

Comment 5 Marc-Andre Lureau 2012-11-29 11:42:00 UTC
(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)

Comment 6 Tomas Jamrisko 2012-11-29 13:15:19 UTC
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.

Comment 7 Hans de Goede 2012-11-29 14:02:37 UTC
(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

Comment 8 David Jaša 2012-11-29 16:46:00 UTC
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.

Comment 9 RHEL Product and Program Management 2012-12-14 08:19:55 UTC
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.

Comment 12 Hans de Goede 2013-01-07 16:07:53 UTC
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.

Comment 14 Hans de Goede 2013-01-09 18:47:34 UTC
I've just posted a patch upstream fixing this:
http://lists.freedesktop.org/archives/spice-devel/2013-January/011970.html

Moving to post.

Comment 15 Hans de Goede 2013-01-09 20:07:19 UTC
The fix for this lives in spice-gtk, updating component.

Comment 16 Hans de Goede 2013-01-10 10:18:31 UTC
Fixed in spice-gtk-0.14-7.el6 moving to modified.

Comment 18 Tomas Jamrisko 2013-01-10 12:07:35 UTC
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.

Comment 20 Hans de Goede 2013-01-10 14:10:05 UTC
(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

Comment 22 Hans de Goede 2013-01-10 18:55:40 UTC
(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.

Comment 25 errata-xmlrpc 2013-02-21 08:49:26 UTC
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


Note You need to log in before you can comment on or make changes to this bug.