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