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 868970 - Multimonitor: change of resolution switches previously disabled display back on
Summary: Multimonitor: change of resolution switches previously disabled display back on
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer
Version: 6.3
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: rc
: 6.8
Assignee: Fabiano Fidêncio
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 1249939
Blocks: 1009648
TreeView+ depends on / blocked
 
Reported: 2012-10-22 15:25 UTC by Milan Barta
Modified: 2015-10-28 00:20 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-17 13:44:05 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Milan Barta 2012-10-22 15:25:16 UTC 
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 10:21:06 UTC 
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 22:40:00 UTC 
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 14:34:46 UTC 
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 06:17:38 UTC 
(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 15:27:46 UTC 
(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 13:44:05 UTC 
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.