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 922391 - second monitor of windows guest gets reenabled right away when disabled inside the guest
Summary: second monitor of windows guest gets reenabled right away when disabled insid...
Keywords:
Status: CLOSED DUPLICATE of bug 952327
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: spice-vdagent-win
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Arnon Gilboa
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-16 15:21 UTC by David Jaša
Modified: 2019-10-10 14:20 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-06 10:29:22 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description David Jaša 2013-03-16 15:21:44 UTC 
Description of problem:
second monitor of windows guest gets reenabled right away when disabled inside the guest

Version-Release number of selected component (if applicable):
guest: windows (7 64b)
vdagent-win-0.1-14
qxl-win-0.1-16
client: any
rhel6:
  virt-viewer-0.5.2-18.el6.x86_64
  spice-gtk-0.14-7.el6.x86_64
winxp:
  mingw-virt-viewer 0.5.3-20.el6ev

How reproducible:
always

Steps to Reproduce:
1. connect to windows VM with two monitors
2. in display properties, disable second monitor
3.
  
Actual results:
before you have a chance to confirm the new layout, 2nd monitor gets re-enabled

Expected results:
2nd monitor gets disabled

Additional info:
when the agent service is not running, the bug does not occur.
Comment 1 Christophe Fergeau 2013-03-18 10:26:29 UTC 
I've seen that during testing last week, though at some point this stopped happening.
Comment 2 Marc-Andre Lureau 2013-03-18 18:41:32 UTC 
That is because the client is (very) regularly asking the agent to change monitor configuration. And the client doesn't have any reliable way to know a monitor has been disabled. In this case, he should close the associated window.

 qxl driver could support MonitorConfig (needs new escape codes for that I guess). There is going to be a bit of cleaning to allow multiple display channel and MonitorConfig simultaneously, until now the two were exclusive.

Since there is an easy workaround, close the client window, I would consider this bug low priority.
Comment 3 Arnon Gilboa 2013-03-21 09:35:03 UTC 
I wouldn't consider it vdagent bug, as that's what the client requests vdagent to do. Marc-Andre, can't it be supported by simply sending VDAgentDisplayConfig from vdagent upon change, and handling it in the client?
Comment 4 Marc-Andre Lureau 2013-03-21 10:55:05 UTC 
(In reply to comment #3)
> I wouldn't consider it vdagent bug, as that's what the client requests
> vdagent to do. Marc-Andre, can't it be supported by simply sending
> VDAgentDisplayConfig from vdagent upon change, and handling it in the client?

That's what I suggested with MonitorConfig, this is what is used already for disabling monitors from the guest on Linux. And it would be less racy, as it is part of display channel messages.
Comment 5 Marc-Andre Lureau 2013-04-26 17:19:26 UTC 
The original bug seems to be fixed, with bug 952327. Please try with mingw-virt-viewer-0.5.3-25, and close that bug as duplicate if the solution is good enough. (The caveat is since the client window stay open, any reconfiguration of client window will re-enable the disabled display)

I have been looking for a good solution to that bug, that would close the client window when the guest monitor is disabled. Unfortunately, it's not easy to do this reliably, and without races.

Since we fixed bug 918997, the client window stay open when the display is disabled. This is an improvement, since when switching to console or rebooting a guest, we shouldn't close (and reopen) client windows.

But the client remains unaware whether the display was disabled temporarily or in guest display settings. The drivers don't have this knowledge either. So eventually, the agent could try to guess the setting change and inform the client. But before the new settings reaches the client to close the window, the display might already be disabled (and reconfigured), since there is no syncrhonization between agent event and display setting event. I am not sure we really want/need that either. 

The best way to really disable a display remains through the client display menu.
Comment 6 David Jaša 2013-05-06 09:44:39 UTC 
(In reply to comment #5)
> The original bug seems to be fixed, with bug 952327. Please try with
> mingw-virt-viewer-0.5.3-25, and close that bug as duplicate if the solution
> is good enough. (The caveat is since the client window stay open, any
> reconfiguration of client window will re-enable the disabled display)
> 

Yes, the mingw-virt-viewer -25 and agent -17 behave that way.

> I have been looking for a good solution to that bug, that would close the
> client window when the guest monitor is disabled. Unfortunately, it's not
> easy to do this reliably, and without races.
> 
> Since we fixed bug 918997, the client window stay open when the display is
> disabled. This is an improvement, since when switching to console or
> rebooting a guest, we shouldn't close (and reopen) client windows.
> 
<...>

Given all this info, I think that the solution is indeed good enough.
Comment 7 Marc-Andre Lureau 2013-05-06 10:29:22 UTC 
fixed by bug 952327

*** This bug has been marked as a duplicate of bug 952327 ***
Note You need to log in before you can comment on or make changes to this bug.