RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 958954 - Disabled display re-appears as they all refresh.
Summary: Disabled display re-appears as they all refresh.
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Virt Viewer Maint
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 953973 957245 973726
Blocks: 1009648
TreeView+ depends on / blocked
 
Reported: 2013-05-02 18:58 UTC by Paul Vine
Modified: 2014-02-20 21:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-20 21:44:37 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Paul Vine 2013-05-02 18:58:47 UTC
Description of problem: I have a 4 display guest running (W7-64) and I diable display 2 through the view menu of the display 2 window. The display goes away and as the remaining windows refresh display 2 is started up again. Also when looking at the view menu I see display 3 as greyed out but it remains active and working properly. Then if I disable display 2 again through it's view menu it goes away for good and display 4 becomes black and says :waiting for display 4...". In order to get display 4 back I have to go into screen res and extend the desktop to that screen. This may be directly related to bug 868970. 

Version-Release number of selected component (if applicable):
Client: RHEL 6.4 64bit
virt-viewer-0.5.2-18.el6_4.2.x86_64
spice-gtk-0.14-7.el6.x86_64

Guest: Windows 7 Enterprise 64bit
RHEV-Tools 3.2.5 with vdagent-win-0.1-17

How reproducible: Every time after the initial connection to the guest.

Steps to Reproduce:
1. Connect to guest with 4 displays configured. Make sure the are all enabled in viewer. Exit and reconnect if needed.
2.Disbale display 2 through view menu of display 2 window.
3.Notice that display 2 reappears after the windows refresh.
4.Notice display 3 is greyed out but still usable.
5. Disable display 2 again.
6. Notice that display 2 is gone, display 3 is not greyed out in the menu, and that display 4 is now a black screen with message "Waiting for display 4...".
  
Actual results:
See steps

Expected results:
Display 2 disabled, nothing greyed out in menu.

Additional info:

Comment 1 Marc-Andre Lureau 2013-05-08 15:46:03 UTC
urgh.. we have many bugs there
- windows vdagent doesnt support sparse monitors bug 953973
- vdagent crashes with some 4 monitor config 957245

Please try again once those bugs are fixed. (my guess is you'll find other multimonitors bugs which are already reported elsewhere)

Comment 2 Paul Vine 2013-12-12 17:13:46 UTC
Tried again since both of those bugs are fixed. I have the same client but am now using guest tool 3.2.7 which has vdagent-win-3.3-2.
Current behaviour:
1. Connect to guest with 4 displays configured. Make sure the are all enabled in viewer. Exit and reconnect if needed.
2. Disable display 2 through view menu of display 2 window.
3. Display 2 is gone (does not come back), display 4 goes black (waiting...), and one time only I lost the visible mouse in display 3.
4. I re-enable display 2 from the view displays and it reappears correctly and also brings back display 4.
5. If I now look at the display menu 1-3 are selectable and selected but display 4 is grayed out (and selected).
5. I disconnect using file-quit and reconnect. All displays appear and are selectable through the menu.
6. Disconnect display 2 through menu and it goes away and immediately reappears. All 4 displays are active but menu shows display 4 as grayed out.

Comment 3 Marc-Andre Lureau 2013-12-12 17:17:11 UTC
if this is windows guest only, I suggest to move the bug to windows vdagent.

Comment 5 Jonathon Jongsma 2014-02-20 21:44:37 UTC
I tried testing this on RHEL6 and wast not able to reproduce. I used the following client versions:

virt-viewer-0.5.6-8.el6.x86_64
virt-viewer-0.5.2-18.el6_4.2.x86_64

However, I did have a more recent spice-gtk installed (0.20.x).  So I tried again on another system with spice-gtk-0.14-7.el6.x86_64, and was able to reproduce the behavior you mention in comment 2.

My conclusion is that this bug was in spice-gtk and it has already be fixed. Since this bug has a rhel-6.6.0? flag, I'm closing this bug.


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