Bug 868970 - Multimonitor: change of resolution switches previously disabled display back on
Multimonitor: change of resolution switches previously disabled display back on
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.3
Unspecified Linux
unspecified Severity low
: rc
: 6.8
Assigned To: Fabiano Fidêncio
Virtualization Bugs
:
Depends On: 1249939
Blocks: 1009648
  Show dependency treegraph
 
Reported: 2012-10-22 11:25 EDT by Milan Barta
Modified: 2015-10-27 20:20 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-17 09:44:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Milan Barta 2012-10-22 11:25:16 EDT
Description of problem:
With multimonitor Windows guest running (Win 7, XP), when a display is disconnected through Control Panel and resolution of any other active display is changed (e.g. by resizing a window or by switching to fullscreen), the previously disabled display is switched on again.

Version-Release number of selected component (if applicable):
Client: RHEL 6.3 64bit
virt-viewer-0.5.2-11.el6.x86_64
spice-gtk-0.14-4.el6.x86_64

Host: Windows 7 Enterprise 64bit, Windows XP Pro 64bit
RHEV-Tools 3.1.8

How reproducible:
Always

Steps to Reproduce:
1. Set up a multimonitor Windows VM (e.g. through RHEVM) and run it
2. Connect to the VM using remote-viewer
3. In the Display settings of guest system activate all displays
4. Disable the previously activated displays so that their window stays black and a message "Waiting for display X..." is shown. Do not close this window.
5. Change the resolution of any active screen (either by resizing the window or by switching to fullscreen or using the Control Panel in guest)
  
Actual results:
All previously disabled displays are switched on again.

Expected results:
The disabled displays stay disabled even after change of resolution of any other active display.

Additional info:
Comment 1 yuping zhang 2012-11-02 06:21:06 EDT
I can reproduce this issue with:
virt-viewer-0.5.2-16.el6.x86_64
libvirt-0.10.2-6.el6.x86_64
spice-gtk-0.14-5.el6.x86_64
spice-server-0.12.0-1.el6.x86_64

The steps are as same as Description.

1. Set up a 2 monitors Windows VM and run it on RHEVM.
2. Connect to the VM using remote-viewer
3. In the Display settings of guest system activate all displays
4. Select the second display,then select "Disconnect this display" -> click apply.
The second display stays black with "Waiting for display 2..."

5. Change the resolution of the first active screen (either by resizing the window or by switching to fullscreen or using the Control Panel in guest)

Result:the second display will be activated again.
Comment 4 Marc-Andre Lureau 2013-05-09 18:40:00 EDT
Sadly, this won't be easily fixable. The Spice client doesn't know if a monitor is disabled temporarily (ex across reboot, or console switch) or permanently. And whenever you resize a monitor, it sends back all monitors/windows config.

Could spice learn to resize a single monitor? Now that we have sparse monitors, perhaps... someone motivated to do that?
Comment 6 Marc-Andre Lureau 2014-06-04 10:34:46 EDT
I don't like to state that, but this bug is pretty much unsolvable.

We can't distinguish between an ephemeral guest display disconnect (across reboots, console switching ..) and a permanent settings change. Trying to guess if the configuration change is permanent will be additional race issues, since those events have no relation.

I think we should consider cantfix here, especially because this is not critical. User should be advised to disable monitors from client instead.
Comment 9 CongDong 2014-11-13 01:17:38 EST
(In reply to Marc-Andre Lureau from comment #6)
> I don't like to state that, but this bug is pretty much unsolvable.
> 
> We can't distinguish between an ephemeral guest display disconnect (across
> reboots, console switching ..) and a permanent settings change. Trying to
> guess if the configuration change is permanent will be additional race
> issues, since those events have no relation.
> 
> I think we should consider cantfix here, especially because this is not
> critical. User should be advised to disable monitors from client instead.

Hi, Marc-Andre
Any update for this bug, or you will close it as cantfix?
Comment 10 Marc-Andre Lureau 2015-03-19 11:27:46 EDT
(In reply to CongDong from comment #9)
> Hi, Marc-Andre
> Any update for this bug, or you will close it as cantfix?

Maybe it's worth taking a second look at this?

I can't remember exactly why the client sends all monitor config, and not just the one that are active.

I think it has to do with console switch and reboot. On a multimonitor setup, when you switch back the guest to graphical from the console mode, it can happen that the first monitor is setup first, and the client sends back the current configuration with a single monitor, while the other monitors aren't yet restored, that will cause bad flickering and disable other monitors in some racy manners.

It's hard to prevent the monitor configuration of being sent back. Timers are often the worst and break other stuff, but the client doesn't know when the guest has finished restoring the configuration. Maybe if there is a way to distinguish client resize due to external events (user / window manager) from the one generate internally (geometry resize), then we could filter this configuration somehow.
Comment 12 David Blechter 2015-10-17 09:44:05 EDT
closing the bug in rhel 6.8, but we'll review the same bug during 7.3 development phase, see https://bugzilla.redhat.com/show_bug.cgi?id=1249939

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