Bug 1262549 - spice-gtk/virt-viewer changes VM resolution even though resize-guest isn't set
Summary: spice-gtk/virt-viewer changes VM resolution even though resize-guest isn't set
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: spice-gtk
Version: 23
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Grunt
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-12 16:33 UTC by Cole Robinson
Modified: 2015-09-14 15:15 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-09-14 15:15:06 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Cole Robinson 2015-09-12 16:33:57 UTC
In testing the patch for bug 1252677 I still hit weird behavior with virt-viewer: resizing the display window still occasionally triggers a resolution change inside the VM. This seems incorrect since virt-viewer hardcodes resize-guest=off.

Looking at this commit message:

commit 4b5e6ec2114e1250c81027ebeac9cfe8d059153f
Author: Pavel Grunt <pgrunt>
Date:   Fri Jul 10 10:37:27 2015 +0200

    Send monitor config if at least one monitor has dimensions
    
    If a client (virt-manager, spicy) is not setting display dimensions
    and the "resize-guest" property is disabled, spice-gtk sends a wrong
    monitor config message where all the monitors have width = heigh = 0
    when the agent connects. This message can confuse the guest, in that
    case the guest will change the resolution of its monitor.

Makes me think that either 1) spice-gtk shouldn't be sending monitor dimensions to the agent if resize-guest=false, or 2) the agent shouldn't be changing the VM resolution ever if resize-guest=false

Comment 1 Pavel Grunt 2015-09-13 08:13:49 UTC
Hi, what is the guest - f23 ?
Does it happen when the connection is established (when the widget is created)?
Does it happen when the agent starts?

Thanks

Comment 2 Cole Robinson 2015-09-13 17:29:35 UTC
(In reply to Pavel Grunt from comment #1)
> Hi, what is the guest - f23 ?

Reproduced with f22 and f23 guests

> Does it happen when the connection is established (when the widget is
> created)?
> Does it happen when the agent starts?
> 

Not sure about these specifics... but I can describe a reproducer.

- Log in to gnome shell in the VM
- Change the display size to 1280x960
- reboot the VM and login again, resolution is correct
- Resize the virt-viewer window... resolution inside the VM is changed to match (_not_ scaling... the VM resolution cleary changes and the 'display' panel lists the new size)

However when I reboot the VM the 1280x960 resolution is restored. Still it seems strange the resolution changes at all without resize-guest set.

Comment 3 Pavel Grunt 2015-09-14 10:12:43 UTC
(In reply to Cole Robinson from comment #2)
> (In reply to Pavel Grunt from comment #1)
> > Hi, what is the guest - f23 ?
> 
> Reproduced with f22 and f23 guests
> 
> > Does it happen when the connection is established (when the widget is
> > created)?
> > Does it happen when the agent starts?
> > 
> 
> Not sure about these specifics... but I can describe a reproducer.
> 
> - Log in to gnome shell in the VM
> - Change the display size to 1280x960
> - reboot the VM and login again, resolution is correct
> - Resize the virt-viewer window... resolution inside the VM is changed to
> match (_not_ scaling... the VM resolution cleary changes and the 'display'
> panel lists the new size)
this is the correct behaviour
> 
> However when I reboot the VM the 1280x960 resolution is restored.
So the bug 1240721 - screen resolution not maintained across reboots in a VM - is not fully fixed.

> Still it
> seems strange the resolution changes at all without resize-guest set.

virt-viewer is not using resize-guest property to resize the guest, it calls spice_main_set_display() instead.

Comment 4 Cole Robinson 2015-09-14 14:20:24 UTC
>> Still it
> > seems strange the resolution changes at all without resize-guest set.
> 
> virt-viewer is not using resize-guest property to resize the guest, it calls
> spice_main_set_display() instead.

Ah, sorry for the misunderstanding... I grepped the logs for resize-guest once and saw danpb's comment disabling it but not the follow up comment enabling it with set_display. Strange it didn't seem to be working at all until recently but maybe that's what you fixed.

I admit though then it's a little strange still... resizing the window sometimes scales it and then resizes the VM, but then sometimes it doesn't resize at all. Seems like maybe scaling shouldn't be used if the agent is connected, but then again this stuff is all prone to breakage so maybe you can't double down on it.

Comment 5 Pavel Grunt 2015-09-14 15:15:06 UTC
(In reply to Cole Robinson from comment #4)
> >> Still it
> > > seems strange the resolution changes at all without resize-guest set.
> > 
> > virt-viewer is not using resize-guest property to resize the guest, it calls
> > spice_main_set_display() instead.
> 
> Ah, sorry for the misunderstanding... I grepped the logs for resize-guest
> once and saw danpb's comment disabling it but not the follow up comment
> enabling it with set_display. Strange it didn't seem to be working at all
> until recently but maybe that's what you fixed.

Probably it was a bug 1212201 in f22 qxl driver which was fixed recently

> 
> I admit though then it's a little strange still... resizing the window
> sometimes scales it and then resizes the VM, but then sometimes it doesn't
> resize at all. Seems like maybe scaling shouldn't be used if the agent is
> connected, but then again this stuff is all prone to breakage so maybe you
> can't double down on it.

There is a couple of patches upstream related to resizing, they should improve the resizing behaviour. Your idea about not scaling also makes sense.

Closing as not a bug, because virt-viewer does not use the "resize-guest" property of the spice-gtk display widget for resizing the guest.


Note You need to log in before you can comment on or make changes to this bug.