Back to bug 1032939

Who When What Removed Added
Daniel Berrangé 2013-12-12 10:58:33 UTC Assignee berrange virt-viewer-maint
Jonathon Jongsma 2013-12-17 15:11:16 UTC Blocks 1009648
John Skeoch 2014-03-17 01:46:04 UTC CC hyao
David Blechter 2014-06-16 12:07:01 UTC Assignee virt-viewer-maint rh-spice-bugs
Jonathon Jongsma 2014-08-19 15:28:03 UTC Status NEW ASSIGNED
CC jjongsma
Assignee rh-spice-bugs jjongsma
John Skeoch 2014-09-07 23:15:00 UTC CC acathrow rbalakri
Jonathon Jongsma 2014-09-26 13:53:57 UTC Status ASSIGNED POST
Fabiano Fidêncio 2014-10-10 12:31:21 UTC CC fidencio
Fabiano Fidêncio 2014-10-13 21:50:43 UTC Status POST MODIFIED
Doc Text Cause: The current design of virt-viewer is that we have a VirtViewerWindow object (the "main window") that is shown at startup in order to communicate session-level connection status to the user. This window is stored in a hash table with a key being the ID of the display (#0, the first display). When we receive a new spice message indicating the maximum number of monitors available (e.g. 4 in the case of a linux guest with QXL), we create display objects for
each of these remote displays, and signal that a new display was added. In response to this signal, we look up the window associated with this display's ID. If the window exists (as it does with display #0), we associate the display with that window. Otherwise, we create a new window, and insert it into the hash table with the display's ID.

Consequence: In cases where the first display is disabled on the guest, we end up with a "main window" that is blank and simply displays the message "Waiting for
display 1...".

Fix: Remove the explicit association of an ID with a particular VirtViewerWindow. In other words, we no longer
maintain a hash table of windows that associate a fixed id with the window object. Instead, we have a simple list of windows, and the ID of that window is determined by the ID of the VirtViewerDisplay object that it contains. In addition, we only create a VirtViewerWindow object for the display when the remote display becomes ready. Disabled remote displays do not have an associated VirtViewerWindow object until they become enabled. This means that the initial window (the "main window") can become any ID: it gets its ID from the first display that becomes enabled.

Result: Virt-viewer no longer pops out invalid Display 1 when relaunching guest
Fabiano Fidêncio 2014-10-13 21:51:21 UTC Fixed In Version virt-viewer-0.6.0-8.el7
errata-xmlrpc 2014-10-13 22:28:39 UTC Status MODIFIED ON_QA
CongDong 2014-10-14 07:09:15 UTC Status ON_QA VERIFIED
John Skeoch 2014-10-19 23:07:31 UTC CC zsong
John Skeoch 2014-11-09 22:26:03 UTC CC lcui
errata-xmlrpc 2015-03-04 18:22:07 UTC Status VERIFIED RELEASE_PENDING
errata-xmlrpc 2015-03-05 13:38:38 UTC Status RELEASE_PENDING CLOSED
Resolution --- ERRATA
Last Closed 2015-03-05 08:38:38 UTC
Jiri Herrmann 2015-07-16 15:06:46 UTC CC jherrman
Doc Text Cause: The current design of virt-viewer is that we have a VirtViewerWindow object (the "main window") that is shown at startup in order to communicate session-level connection status to the user. This window is stored in a hash table with a key being the ID of the display (#0, the first display). When we receive a new spice message indicating the maximum number of monitors available (e.g. 4 in the case of a linux guest with QXL), we create display objects for
each of these remote displays, and signal that a new display was added. In response to this signal, we look up the window associated with this display's ID. If the window exists (as it does with display #0), we associate the display with that window. Otherwise, we create a new window, and insert it into the hash table with the display's ID.

Consequence: In cases where the first display is disabled on the guest, we end up with a "main window" that is blank and simply displays the message "Waiting for
display 1...".

Fix: Remove the explicit association of an ID with a particular VirtViewerWindow. In other words, we no longer
maintain a hash table of windows that associate a fixed id with the window object. Instead, we have a simple list of windows, and the ID of that window is determined by the ID of the VirtViewerDisplay object that it contains. In addition, we only create a VirtViewerWindow object for the display when the remote display becomes ready. Disabled remote displays do not have an associated VirtViewerWindow object until they become enabled. This means that the initial window (the "main window") can become any ID: it gets its ID from the first display that becomes enabled.

Result: Virt-viewer no longer pops out invalid Display 1 when relaunching guest 		The first guest display was re-enabled after a guest reboot even when it was previously disabled on the guest. This update removes the fixed association between the the main guest window and a specific guest display number, which prevents the problem from occurring.

Back to bug 1032939