Bug 922391
| Summary: | second monitor of windows guest gets reenabled right away when disabled inside the guest | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | David Jaša <djasa> |
| Component: | spice-vdagent-win | Assignee: | Arnon Gilboa <agilboa> |
| Status: | CLOSED DUPLICATE | QA Contact: | Desktop QE <desktop-qa-list> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | --- | CC: | acathrow, cfergeau, dblechte, dyasny, marcandre.lureau, pvine |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-05-06 10:29:22 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: | |||
|
Description
David Jaša
2013-03-16 15:21:44 UTC
I've seen that during testing last week, though at some point this stopped happening. That is because the client is (very) regularly asking the agent to change monitor configuration. And the client doesn't have any reliable way to know a monitor has been disabled. In this case, he should close the associated window. qxl driver could support MonitorConfig (needs new escape codes for that I guess). There is going to be a bit of cleaning to allow multiple display channel and MonitorConfig simultaneously, until now the two were exclusive. Since there is an easy workaround, close the client window, I would consider this bug low priority. I wouldn't consider it vdagent bug, as that's what the client requests vdagent to do. Marc-Andre, can't it be supported by simply sending VDAgentDisplayConfig from vdagent upon change, and handling it in the client? (In reply to comment #3) > I wouldn't consider it vdagent bug, as that's what the client requests > vdagent to do. Marc-Andre, can't it be supported by simply sending > VDAgentDisplayConfig from vdagent upon change, and handling it in the client? That's what I suggested with MonitorConfig, this is what is used already for disabling monitors from the guest on Linux. And it would be less racy, as it is part of display channel messages. The original bug seems to be fixed, with bug 952327. Please try with mingw-virt-viewer-0.5.3-25, and close that bug as duplicate if the solution is good enough. (The caveat is since the client window stay open, any reconfiguration of client window will re-enable the disabled display) I have been looking for a good solution to that bug, that would close the client window when the guest monitor is disabled. Unfortunately, it's not easy to do this reliably, and without races. Since we fixed bug 918997, the client window stay open when the display is disabled. This is an improvement, since when switching to console or rebooting a guest, we shouldn't close (and reopen) client windows. But the client remains unaware whether the display was disabled temporarily or in guest display settings. The drivers don't have this knowledge either. So eventually, the agent could try to guess the setting change and inform the client. But before the new settings reaches the client to close the window, the display might already be disabled (and reconfigured), since there is no syncrhonization between agent event and display setting event. I am not sure we really want/need that either. The best way to really disable a display remains through the client display menu. (In reply to comment #5) > The original bug seems to be fixed, with bug 952327. Please try with > mingw-virt-viewer-0.5.3-25, and close that bug as duplicate if the solution > is good enough. (The caveat is since the client window stay open, any > reconfiguration of client window will re-enable the disabled display) > Yes, the mingw-virt-viewer -25 and agent -17 behave that way. > I have been looking for a good solution to that bug, that would close the > client window when the guest monitor is disabled. Unfortunately, it's not > easy to do this reliably, and without races. > > Since we fixed bug 918997, the client window stay open when the display is > disabled. This is an improvement, since when switching to console or > rebooting a guest, we shouldn't close (and reopen) client windows. > <...> Given all this info, I think that the solution is indeed good enough. fixed by bug 952327 *** This bug has been marked as a duplicate of bug 952327 *** |