Bug 1086657

This is expected behavior.

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.

You cannot enable a second monitor via the virt-viewer 'view > displays' menu?

(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.

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.

Oops, accidentally reassigned to incorrect component.  Moving to qxl for now, but that might not be the right place either...

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.

*** Bug 1086656 has been marked as a duplicate of this bug. ***

*** Bug 1086656 has been marked as a duplicate of this bug. ***

this is weird, I could reproduce at some point and now I can no longer reproduce

I can reproduce again, it was enough to simply turn off secondary monitor from Display Preference then try to turn it on.

(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.

(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

Patches mentioned in comment #15 never made it upstream, moving the bug back to NEW.

We are 2 to agree with the proposed patch, so moving back to POST

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

For the record, the patch proposed as solution for this bug is responsible for bug 1130080.