Bug 868970
Summary: | Multimonitor: change of resolution switches previously disabled display back on | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Milan Barta <mbarta> |
Component: | virt-viewer | Assignee: | Fabiano FidĂȘncio <fidencio> |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | low | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.3 | CC: | cfergeau, cwei, dblechte, dyuan, fidencio, juzhou, marcandre.lureau, mjenner, mzhan, rbalakri, tpelka, tzheng |
Target Milestone: | rc | ||
Target Release: | 6.8 | ||
Hardware: | Unspecified | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-10-17 13:44:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1249939 | ||
Bug Blocks: | 1009648 |
Description
Milan Barta
2012-10-22 15:25:16 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. 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? 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. (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? (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. 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 |