Bug 1249939 - 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 7
Classification: Red Hat
Component: virt-viewer (Show other bugs)
7.2
x86_64 Unspecified
medium Severity low
: rc
: 7.2
Assigned To: Virt Viewer Maint
Virtualization Bugs
:
Depends On:
Blocks: 868970
  Show dependency treegraph
 
Reported: 2015-08-04 04:13 EDT by zhoujunqin
Modified: 2018-01-19 14:05 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-01-19 14:05:46 EST
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)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 92507 None None None 2016-07-13 04:29 EDT

  None (edit)
Description zhoujunqin 2015-08-04 04:13:49 EDT
Description of problem:
With multimonitor Windows guest running (eg: Win 7), 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 7.2 latest(installed with tree:http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL-7.2-20150720.0/compose/Server/x86_64/os/)

virt-viewer-2.0-5.el7.x86_64
spice-gtk-0.26-4.el7.x86_64


How reproducible:
100%

Steps to Reproduce:

1. Prepare a windows 7 guest(x86_64) on RHEVM, make sure has spice graphic with 4 monitors, and install rhev-guest-tools-iso.

2. Connect to guest.(Right click guest-->console)

3. Extend its desktop to 4 displays.

4. Right click on desktop->Screen resolution, choose second display, then click "Disconnect this display" -> click apply.

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)

Actual results:
After step4, the second display stays black with "Waiting for display 2...".
After step5,the second display will be activated again.

Expected results:
After step5, disabled display(the second display) still keep disabled.

Additional info:
Comment 2 Pavel Grunt 2015-08-04 07:30:25 EDT
clone of bug 868970
Comment 4 Jonathon Jongsma 2015-08-04 11:28:38 EDT
Just for convenience, I'll copy this here. I agree with Marc-Andre on bug868970 comment 6, where he says this:

> 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 5 David Blechter 2015-10-17 09:45:58 EDT
(In reply to Jonathon Jongsma from comment #4)
> Just for convenience, I'll copy this here. I agree with Marc-Andre on
> bug868970 comment 6, where he says this:
> 
> > 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.

let's revisit based on https://bugzilla.redhat.com/show_bug.cgi?id=868970#c10 proposal.
Comment 6 David Blechter 2015-10-17 09:46:29 EDT
(In reply to Jonathon Jongsma from comment #4)
> Just for convenience, I'll copy this here. I agree with Marc-Andre on
> bug868970 comment 6, where he says this:
> 
> > 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.

let's revisit based on https://bugzilla.redhat.com/show_bug.cgi?id=868970#c10 proposal.
Comment 7 David Blechter 2015-10-17 10:33:58 EDT
set devel cond nack upstream. For reference: the upstream bug was opened https://bugs.freedesktop.org/show_bug.cgi?id=92507
Comment 9 Pavel Grunt 2016-02-18 05:57:44 EST
still no solution upstream
Comment 10 David Blechter 2016-12-12 08:12:25 EST
(In reply to Pavel Grunt from comment #9)
> still no solution upstream

moving to 7.5
Comment 11 David Blechter 2018-01-19 14:05:46 EST
there is no solution upstream for +2 years, closing.

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