Bug 908057
Summary: | Cannot change resolution when View -> Automatically resize in RV is off | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Milan Barta <mbarta> | ||||||||
Component: | virt-viewer | Assignee: | Marc-Andre Lureau <marcandre.lureau> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | 6.4 | CC: | acathrow, cfergeau, codong, dblechte, dyuan, hdegoede, hyao, lcui, lnovich, marcandre.lureau, mjenner, tjamrisk, tpelka, tzheng | ||||||||
Target Milestone: | rc | ||||||||||
Target Release: | 6.5 | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | virt-viewer-0.5.6-1.el6 | Doc Type: | Bug Fix | ||||||||
Doc Text: |
Cause:
When option View -> Automatically resize in remote-viewer is off and resolution on guest is changed (for example via Display Preferences in Gnome).
Consequence:
The resolution changes, however after a moment, the resolution reverts back to the previous state.
Fix:
Keep monitor configuration in sync with the guest, even when automatic resize is disabled.
Result:
The resolution doesn't revert back after change from the guest.
|
Story Points: | --- | ||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2013-11-21 08:07:24 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: | |||||||||||
Attachments: |
|
Description
Milan Barta
2013-02-05 18:10:21 UTC
Created attachment 693504 [details]
vdagent log
Created attachment 693505 [details]
remote-viewer --spice-debug log
Noticed exactly the same behaviour on 64 bit Windows 7 guests. Hmm, this works for me, at least in windowed mode. Is this in fullscreen or windowed mode ? If in fullscreen mode, this is more or less expected and it seems the problem here is that the "automatically resize" option does other things then people seem to expect. It disables automatically resizing the window size to match the guest resolution (so as to stop the window resizing all the time during boot when changing between different text and gfx modes). It does *not* disable resizing in the other direction, where the client asks the guest-agent to change the guest resolution to match it. And since in fullscreen mode the window cannot be resized, after 1 second the client asks the guest-agent to change the guest resolution to match its "new" window size, and your back to the resolution your client is running at. Oh wait, I can reproduce even in windowed mode. I had to turn "automatically resize" off to reproduce in windowed mode, since then the window won't resize, just like in fullscreen mode. So the question is how should we behave in this case? I guess the most consistent thing to do would be to also disable client -> guest resizing when "automatically resize" is off. Marc-André what is your take on this? (In reply to comment #5) > So the question is how should we behave in this case? I guess the most > consistent thing to do would be to > also disable client -> guest resizing when "automatically resize" is off. > Marc-André what is your take on this? Hmm, I think I understand the bug is that we enable/disable monitors still, which may trigger reconfiguration with old "main-channel monitors" values. See proposed patch which seems to work.. Created attachment 694154 [details]
spice-gtk patch
I think it should be d->monitor_id + d->channel_id, just like virt-viewer code (In reply to comment #8) > I think it should be d->monitor_id + d->channel_id, just like virt-viewer > code Actually, it should use get_display_id(display), like all the other calls to spice_main_set_display* in spice-widget.c (In reply to comment #7) > Created attachment 694154 [details] > spice-gtk patch Looks good, ack with the above change added. (In reply to comment #9) > (In reply to comment #8) > > I think it should be d->monitor_id + d->channel_id, just like virt-viewer > > code > > Actually, it should use get_display_id(display), like all the other calls to > spice_main_set_display* in spice-widget.c yes > (In reply to comment #7) > > Created attachment 694154 [details] > > spice-gtk patch > > Looks good, ack with the above change added. thanks, pushed I can reproduce this bug: Version and Steps are same as description. result: The resolution changes to the new one but immediately reverts back to the previous state. Verify: Version: # rpm -qa | grep spice spice-server-0.12.3-1.el6.x86_64 spice-vdagent-0.14.0-1.el6.x86_64 spice-gtk-0.20-1.el6.x86_64 spice-gtk-python-0.20-1.el6.x86_64 spice-client-0.8.2-15.el6.x86_64 spice-glib-0.20-1.el6.x86_64 # rpm -qa virt-viewer virt-viewer-0.5.6-1.el6.x86_64 Steps: Same as description. Result: The resolution didn't revert back after changed it to the new one. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-1578.html |