|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>|
|Version:||6.4||CC:||acathrow, cfergeau, codong, dblechte, dyuan, hdegoede, hyao, lcui, lnovich, marcandre.lureau, mjenner, tjamrisk, tpelka, tzheng|
|Fixed In Version:||virt-viewer-0.5.6-1.el6||Doc Type:||Bug Fix|
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.
|Last Closed:||2013-11-21 08:07:24 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Milan Barta 2013-02-05 18:10:21 UTC
Description of problem: When option View -> Automatically resize in remote-viewer is off and resolution on guest is changed (for example via Display Preferences in Gnome), the resolution changes, however after a moment, the resolution reverts back to the previous state. Version-Release number of selected component (if applicable): Host and Client: RHEL 6.4 x86_64 -------------------------------- virt-viewer-0.5.2-16.el6.x86_64 spice-gtk-0.14-7.el6.x86_64 spice-server-0.12.0-12.el6.x86_64 qemu-kvm-0.12.1.2-2.355.el6.x86_64 Guest: RHEL 6.4 x86_64 ---------------------- spice-vdagent-0.12.0-4.el6.x86_64 xorg-x11-drv-qxl-0.1.0-4.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. connect to a VM using remote-viewer 2. uncheck option View -> Automatically resize in remote-viewer's menu 3. change the guest resolution using the Gnome Display Preferences dialog Actual results: The resolution changes to the new one but immediately reverts back to the previous state. Expected results: The newly set resolution changes and stays set. Additional info:
Comment 2 Milan Barta 2013-02-05 18:12:55 UTC
Created attachment 693505 [details] remote-viewer --spice-debug log
Comment 3 Tomas Jamrisko 2013-02-06 14:57:14 UTC
Noticed exactly the same behaviour on 64 bit Windows 7 guests.
Comment 4 Hans de Goede 2013-02-06 16:48:36 UTC
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.
Comment 5 Hans de Goede 2013-02-06 16:53:28 UTC
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?
Comment 6 Marc-Andre Lureau 2013-02-06 21:45:32 UTC
(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..
Comment 7 Marc-Andre Lureau 2013-02-06 21:46:10 UTC
Created attachment 694154 [details] spice-gtk patch
Comment 8 Marc-Andre Lureau 2013-02-06 21:50:33 UTC
I think it should be d->monitor_id + d->channel_id, just like virt-viewer code
Comment 9 Hans de Goede 2013-02-07 19:38:23 UTC
(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.
Comment 10 Marc-Andre Lureau 2013-02-07 22:01:12 UTC
(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
Comment 17 CongDong 2013-07-08 02:42:23 UTC
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.
Comment 18 errata-xmlrpc 2013-11-21 08:07:24 UTC
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