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 1086657 - Cannot get same result when enabled second monitor after disabled it in guest with "Display Perference"
Summary: Cannot get same result when enabled second monitor after disabled it in guest...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-vdagent
Version: 6.6
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Default Assignee for SPICE Bugs
QA Contact: SPICE QE bug list
URL:
Whiteboard:
: 1086656 (view as bug list)
Depends On: 1086656
Blocks: 1349852
TreeView+ depends on / blocked
 
Reported: 2014-04-11 09:13 UTC by CongDong
Modified: 2016-06-24 11:27 UTC (History)
11 users (show)

Fixed In Version: spice-vdagent-0.14.0-9.el6
Doc Type: Bug Fix
Doc Text:
Cause: Under certain conditions, a race could occur between the guest gnome-settings-daemon and enabling a display from the SPICE client Consequence: reenabling a disabled display from the SPICE client would not be possible Fix: Make sure gnome-settings daemon does not attempt to enable/disable displays by itself Result: reenabling displays from the SPICE client works fine
Clone Of: 1086656
: 1349852 (view as bug list)
Environment:
Last Closed: 2015-07-22 07:28:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1392 0 normal SHIPPED_LIVE spice-vdagent bug fix update 2015-07-20 17:58:05 UTC

Description CongDong 2014-04-11 09:13:36 UTC 
+++ This bug was initially created as a clone of Bug #1086656 +++

Can reproduce this with:
virt-viewer-0.5.6-8.el6
So clone it.


Description of problem:
If disable the second monitor with "Display Preference", then cannot find "Monitor 2" and enabled it again.

Version-Release number of selected component (if applicable):
virt-viewer-0.5.7-7.el7.x86_64

How reproducible:
60%

Steps to Reproduce:
1. Prepare a rhel6 guest with spice graphic.
2. # virt-viewer rhel6
   Open display 2, make sure the two displays are all work well.
3. Open "Display Preference" in guest.
   System -> Preferences -> Display
4. Choose the monitor which correspond to display 2, and choose "Off", then click "Apply"
   Now, display 2 should be disconnected, and monitor 2 is turned black.
5. Close display 2 by virt-viewer's "view" menu and close "Display preference"
6. Reopen "Display preference", after that open display 2.
   Now, display 2 is disconnected, and status of monitor 2 in "Display preference" is "off"
7. Choose monitor 2 and turn it on.

Actual results:
Step7, after turn monitor 2 on, display 2 is still disconnected, and monitor 2 is disappeared in "Display preference".

Expected results:
Can enable monitor 2 sucessfully.

Additional info:
Comment 2 Jonathon Jongsma 2014-04-11 15:09:51 UTC 
This is expected behavior.
Comment 3 CongDong 2014-04-14 09:59:37 UTC 
As the result in description, I cannot enalbed the monitor after step 7.
But I cannot get this result everytime.
The monitor can be enabled sometime.

So, I think it's a bug and should reopen it.
Comment 4 Jonathon Jongsma 2014-04-14 13:58:16 UTC 
You cannot enable a second monitor via the virt-viewer 'view > displays' menu?
Comment 5 CongDong 2014-04-15 01:20:34 UTC 
(In reply to Jonathon Jongsma from comment #4)
> You cannot enable a second monitor via the virt-viewer 'view > displays'
> menu?

Yes, when I said in actual result, the display 2 is still disconnected.
Comment 6 Jonathon Jongsma 2014-04-15 18:30:34 UTC 
After turning off the display in the guest 'display preferences' application, xrandr indicates that this display is 'disconnected'.  Also, if you click 'Detect displays' at this point, the disabled display will generally disappear from the UI. 

But this does not appear to be a bug in virt-viewer.  It is more likely a bug in the guest somewhere.  Perhaps in the 'display preferences' application. Or possibly in the qxl driver or the vdagent (although the vdagent shouldn't really be relevant when disabling/enabling guests entirely within the guest display preferences tool).

Here's a bit more information.  xrandr -q when 2 displays are enabled:

$ xrandr -q
Screen 0: minimum 320 x 200, current 1824 x 768, maximum 8192 x 8192
qxl-0 connected 1024x768+0+0 0mm x 0mm
   1024x768       60.0*+
   2560x1600      60.0  
   2000x2000      60.0  
   2560x1440      60.0  
   2048x1536      60.0  
   1920x1440      60.0  
   1920x1200      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1600x900       60.0  
   1280x1024      60.0  
   1440x900       60.0  
   1280x960       60.0  
   1366x768       60.0  
   1360x768       60.0  
   1280x800       60.0  
   1152x870       60.0  
   1152x864       60.0  
   1280x768       60.0  
   1280x760       60.0  
   1280x720       60.0  
   1024x600       60.0  
   960x640        60.0  
   832x624        60.0  
   800x600        60.0  
   800x480        60.0  
   640x480        60.0  
qxl-1 connected 800x600+1024+0 0mm x 0mm
   1024x768       60.0 +
   2560x1600      60.0  
   2000x2000      60.0  
   2560x1440      60.0  
   2048x1536      60.0  
   1920x1440      60.0  
   1920x1200      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1600x900       60.0  
   1280x1024      60.0  
   1440x900       60.0  
   1280x960       60.0  
   1366x768       60.0  
   1360x768       60.0  
   1280x800       60.0  
   1152x870       60.0  
   1152x864       60.0  
   1280x768       60.0  
   1280x760       60.0  
   1280x720       60.0  
   1024x600       60.0  
   960x640        60.0  
   832x624        60.0  
   800x600        60.0* 
   800x480        60.0  
   640x480        60.0  
qxl-2 disconnected
qxl-3 disconnected


And after disabling display 2 via the guest display prefs tool:

$ xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192
qxl-0 connected 1024x768+0+0 0mm x 0mm
   1024x768       60.0*+
   2560x1600      60.0  
   2000x2000      60.0  
   2560x1440      60.0  
   2048x1536      60.0  
   1920x1440      60.0  
   1920x1200      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1600x900       60.0  
   1280x1024      60.0  
   1440x900       60.0  
   1280x960       60.0  
   1366x768       60.0  
   1360x768       60.0  
   1280x800       60.0  
   1152x870       60.0  
   1152x864       60.0  
   1280x768       60.0  
   1280x760       60.0  
   1280x720       60.0  
   1024x600       60.0  
   960x640        60.0  
   832x624        60.0  
   800x600        60.0  
   800x480        60.0  
   640x480        60.0  
qxl-1 disconnected
   800x600-1       0.1  
qxl-2 disconnected
qxl-3 disconnected


I can sometimes enable the second display with the following command within the guest:

   xrandr --output qxl-1 --right-of qxl-0 --mode 800x600-1

(Where "800x600-1" is the mode listed in the xrandr output)

However, I've also seen cases where there are NO modes listed under the qxl-1 section.  In this case, the only way I'm able to re-enable the second display is by closing the second display window in virt-viewer (view > display > display 2) and then re-opening it again.
Comment 7 Jonathon Jongsma 2014-04-15 18:39:13 UTC 
Oops, accidentally reassigned to incorrect component.  Moving to qxl for now, but that might not be the right place either...
Comment 8 Jonathon Jongsma 2014-04-15 19:03:20 UTC 
Another note: When performing the same procedure on e.g. a fedora 19 guest running on a Fedora 20 host, the xrandr output after disabling the 2nd display still shows the device as connected and lists all of the same modes that it had before being disabled.
Comment 9 Jonathon Jongsma 2014-04-16 14:51:25 UTC 
*** Bug 1086656 has been marked as a duplicate of this bug. ***
Comment 11 Cui Lei 2014-06-25 05:01:20 UTC 
*** Bug 1086656 has been marked as a duplicate of this bug. ***
Comment 12 Marc-Andre Lureau 2014-08-15 17:49:05 UTC 
this is weird, I could reproduce at some point and now I can no longer reproduce
Comment 13 Marc-Andre Lureau 2014-08-19 12:25:23 UTC 
I can reproduce again, it was enough to simply turn off secondary monitor from Display Preference then try to turn it on.
Comment 14 Marc-Andre Lureau 2014-08-25 12:43:07 UTC 
(In reply to Marc-Andre Lureau from comment #13)
> I can reproduce again, it was enough to simply turn off secondary monitor
> from Display Preference then try to turn it on.

forget that, turning off a monitor will "disconnect" it, so it must be open again from spice client.

Getting back to original bug description, the problem comes from gnome-settings-daemon, when re-opening the off monitor, for some reason the change_timestamp < config_timestamp, so gsd will apply its own configuration, disabling the to be enabled monitor.
Comment 15 Marc-Andre Lureau 2014-08-27 17:24:15 UTC 
(In reply to Marc-Andre Lureau from comment #14)
> change_timestamp < config_timestamp, so gsd will apply its own
> configuration, disabling the to be enabled monitor.

The config_timestamp is updated by X server in various conditions, when a mode is added/deleted or when a screen size changes (the effective update is when gss or other app query server infos after notification).

These condition are triggered by vdagent during monitor config. Since we can't control the timestamps, and playing with extra delay will be inherently racy,  
the only sane way I can think of is to disable gsd behaviour. This can be achieved by deleting the ~/.config/monitors.xml, which is the intended configuration to restore, so vdagent will override whatever configuration was saved previously.

Somehow, if vdagent would be better integrated with gnome2, it would use the gnome-rr and/or org.gnome.SettingsDaemon.XRANDR dbus API (In gnome3, the monitor configuration has been merged in)

With the proposed patch, I noticed in some cases that gsd would apply a different auto-configuration, which will confuse pointer, I sent a patch for that too.

http://lists.freedesktop.org/archives/spice-devel/2014-August/017275.html
Comment 17 Christophe Fergeau 2015-03-02 17:21:28 UTC 
Patches mentioned in comment #15 never made it upstream, moving the bug back to NEW.
Comment 18 Marc-Andre Lureau 2015-03-19 10:52:49 UTC 
We are 2 to agree with the proposed patch, so moving back to POST
Comment 22 errata-xmlrpc 2015-07-22 07:28:00 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.

https://rhn.redhat.com/errata/RHBA-2015-1392.html
Comment 23 Eduardo Lima (Etrunko) 2015-10-02 21:02:47 UTC 
For the record, the patch proposed as solution for this bug is responsible for bug 1130080.
Note You need to log in before you can comment on or make changes to this bug.