Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 958263

Summary: Unchecking displays in virt-viewer disables that display from coming back unless you relaunch from RHEV-M
Product: Red Hat Enterprise Virtualization Manager Reporter: Bill Sanford <bsanford>
Component: mingw-virt-viewerAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED CURRENTRELEASE QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: cfergeau, cpelland, dblechte, fidencio, mkrcmari, pvine, rbalakri, vipatel
Target Milestone: ---Keywords: ZStream
Target Release: 3.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: mingw-virt-viewer-2.0-1.el7ev Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 973729 (view as bug list) Environment:
Last Closed: 2015-07-24 15:40:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 953973, 973726    
Bug Blocks: 973729    

Description Bill Sanford 2013-04-30 18:22:28 UTC
Description of problem:
With multiple displays, if you deselect a display (View -> Displays) and try to select it to come back, it will come back as a black screen.

In the following matrix, if you deselect a display and select it to return, you will have that display return as a black screen. If you do this on the second or third display, it will temporarily disable the next display until you enable the display you just deselected.

Display    1    2    3    4
           x                  1 comes back black
                x             2 comes back black, temp disables 3
                     x        1 comes back black, temp disables 4
                          x   4 comes back black

Version-Release number of selected component (if applicable):
RHEV-M 3.2 (si14)
spice-client-msi-3.2-10
mingw-virt-viewer 0.5.3-25

How reproducible:
100%

Steps to Reproduce:
1. See above
2. 
3.
  
Actual results:
See above matrix.

Expected results:
Deselected displays should return as they were and not black screens.

Additional info:
If you close the VM and relaunch it through RHEV-M, everything works.

Comment 2 Bill Sanford 2013-05-01 13:02:27 UTC
Since the functionality has changed from closing out each display (With the "X" of the virt-viewer window) to now having to select or deselect the display in the virt-viewer menu, is it possible to get a synopsis of the intended functionality changes so that QE and Docs can also be on the same page? Should this affect any other functionality in virt-viewer?

Comment 3 Christophe Fergeau 2013-05-01 13:28:28 UTC
Before, clicking the 'X' on one virt-viewer/remote-viewer window would close just that window, and would disable the corresponding screen in the guest OS. This behaviour could be confusing if you exit virt-viewer by closing its windows one by one using the 'X' button: when you restart it, you only have 1 screen available, while when you decided to quit it, you had multiple screens available.

With this build, clicking the 'X' button on one virt-viewer/remote-viewer window will (try to) quit the whole application. This way, when you restart remote-viewer, you'll get as many displays opened as you had when you decided to quit it.

The "X" button should be the only thing impacted by these changes, in particular the display menu should work exactly as in older builds.

Bill, do you need more details or is it enough?

Comment 4 Bill Sanford 2013-05-01 13:52:22 UTC
This is good information. Now we can write test plans for the changes and start filing doc bugs. Thanks, Christophe!

Comment 5 Marian Krcmarik 2013-05-02 17:50:38 UTC
Not sure what vdagent was used but with latest 0.1-17 It seems that the monitors in my testing come back properly but still some other seems to be disabled as stated in the matrix.

I can reproduce:

Display    1    2    3    4
           x                  1 comes back black
                x             2 comes back, temp disables 3
                     x        1 comes back, temp disables 4
                          x   4 comes black

Note: resize of r-v window triggers agent to resize and solves problem.

Comment 6 Bill Sanford 2013-05-02 18:05:06 UTC
I originally tested with the following:

RHEV-M 3.2 (si14)
spice-client-msi-3.2-10
mingw-virt-viewer 0.5.3-25

The vdagent-win-0.1-16 came with that particular install.

I have since added vdagent-win-0.1-17 and the results are far improved.

Display    1    2    3    4
           x                  1 comes back black *** This is separate bug.
                x             2 comes back, temp disables 4
                     x        1 comes back, temp disables 4
                          x   4 comes back

After you disable any display that isn't display 1, everything comes back as normal and just temp disables display 4.

Note: resize of r-v window triggers agent to resize and solves problem. *** Only needed with display 1, now.

Comment 7 Marc-Andre Lureau 2013-05-06 00:12:47 UTC
Bill, can you verify your guest is properly configured, and the 4 drivers are correctly loaded (check that the 4 monitors are available in guest display settings)

Comment 8 Marian Krcmarik 2013-05-06 09:53:24 UTC
(In reply to comment #7)
> Bill, can you verify your guest is properly configured, and the 4 drivers
> are correctly loaded (check that the 4 monitors are available in guest
> display settings)

Yes it is, in my setup as well as in Bill's. Btw. How would I get 4 monitors on Windows guest without 4 qxl drivers? The problem is that If you disabled 2nd or 3th monitor, monitor the number 4 is disabled.

Comment 9 Marc-Andre Lureau 2013-05-07 16:40:05 UTC
beside the fact that monitor 1 can't really be disabled from client side atm, I think the main reason for these black screen is the race between the main channel display config timer and the initialization of all the display.

I don't know yet how the client or spice-gtk could decide when to hold and fire the monitar configuration event to avoid that race...

Comment 10 Marc-Andre Lureau 2013-05-09 10:59:23 UTC
patch sent to ML for case 1.
https://www.redhat.com/archives/virt-tools-list/2013-May/msg00017.html

Adding sparse monitor support bug dependency

Comment 12 Marc-Andre Lureau 2013-06-13 14:42:32 UTC
moving back to ASSIGN, as there is only a partial solution so far.

Comment 13 David Blechter 2013-08-22 12:34:48 UTC
the full solution will require changes on the guest side meaning qxl dirver and vdagent. 
As the result - moving to the next release

Comment 14 David Blechter 2014-02-11 23:17:24 UTC
there are no plans for whql for 3.4, but changes are required in qxl driver. As the result moving to future releases

Comment 16 Fabiano FidĂȘncio 2015-07-24 15:40:47 UTC
After some tests I could verify that this bug has been fixed by the re-base to virt-viewer 2.0 (+ sync with the patches used for rhel-6.7).
Closing as CURRENTRELEASE.