Bug 1269292 - Auto re-size only works with > 1 display. No auto resizing of single display.
Auto re-size only works with > 1 display. No auto resizing of single display.
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.7
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Virt Viewer Maint
Virtualization Bugs
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-06 17:38 EDT by Bill Sanford
Modified: 2015-10-08 14:49 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-08 11:04:32 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Sanford 2015-10-06 17:38:42 EDT
Description of problem:
The only way to set the resolution in a single display of virt-viewer is through the System Tools -> Settings -> Displays and not re-sizing the window. If you add more than one display in virt-viewer, the auto re-sizing (Of all displays) works great. If you re-size the single display, it will scale to the set size of the resolution that was set with the System Tools -> Settings -> Displays.

When I am using multiple displays, and re-sizing them without issue, I will remove all but display 1 and then the re-sized SPICE display, will always go back to the resolution of the configured display and not stay as the new re-sized display.

Version-Release number of selected component (if applicable):

Host and Client - RHEL-6.7-20150811.1
Guest - RHEL-7.1-20150219.1/

On host and client:
virt-viewer-2.0-7.el6.x86_64
spice-glib-0.26-4.el6.x86_64
spice-gtk-python-0.26-4.el6.x86_64
spice-gtk-0.26-4.el6.x86_64
spice-server-0.12.4-12.el6.x86_64
spice-vdagent-0.14.0-9.el6.x86_64
usbredir-0.5.1-2.el6.x86_64


How reproducible:
100%

Steps to Reproduce:
1.
2.
3.

Actual results:
No auto re-sizing of single display, only in > 1 display.

Expected results:
Auto re-sizing of single display.

Additional info:

I tried to tail different log files but nothing showed up when the failure happens, just when the auto re-size worked.
Comment 2 Pavel Grunt 2015-10-07 04:52:31 EDT
It looks more like a guest problem (e.g. bug 1242847) rather than the regression on the client side.
Can you tell the version of virt-viewer & spice-gtk in which it was working?
Comment 3 Bill Sanford 2015-10-07 08:53:02 EDT
The reason I say it is virt-viewer, is that I have 1440 x 900 set with System Tools -> Settings -> Displays. With one display window re-sized smaller or bigger, the correct resolution is being noticed and NOT set by virt-viewer. This is NOT a problem with more than one display.

As you can see, I re-sized the display to 1760x966:

[root@localhost log]# xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
Virtual-0 connected primary 1440x900+0+0 0mm x 0mm
   1760x966       59.9 +
   1920x1200      59.9  
   1920x1080      60.0  
   1600x1200      59.9  
   1680x1050      60.0  
   1400x1050      60.0  
   1280x1024      59.9  
   1440x900       59.9* 
   1280x960       59.9  
   1280x854       59.9  
   1280x800       59.8  
   1280x720       59.9  
   1152x768       59.8  
   1024x768       59.9  
   800x600        59.9  
   848x480        59.7  
   720x480        59.7  
   640x480        59.4  
Virtual-1 disconnected
Virtual-2 disconnected
Virtual-3 disconnected
[root@localhost log]# 

As you can see, I re-sized the display to 1368x565:

[root@localhost log]# xrandr
Screen 0: minimum 320 x 200, current 1440 x 900, maximum 8192 x 8192
Virtual-0 connected primary 1440x900+0+0 0mm x 0mm
   1368x565       59.8 +
   1920x1200      59.9  
   1920x1080      60.0  
   1600x1200      59.9  
   1680x1050      60.0  
   1400x1050      60.0  
   1280x1024      59.9  
   1440x900       59.9* 
   1280x960       59.9  
   1280x854       59.9  
   1280x800       59.8  
   1280x720       59.9  
   1152x768       59.8  
   1024x768       59.9  
   800x600        59.9  
   848x480        59.7  
   720x480        59.7  
   640x480        59.4  
Virtual-1 disconnected
Virtual-2 disconnected
Virtual-3 disconnected
[root@localhost log]#
Comment 4 Jonathon Jongsma 2015-10-07 09:36:16 EDT
I agree with Pavel. I'm almost certain this is a guest bug. It doesn't happen on rhel6 guests because spice-vdagent removes the ~/.config/monitors.xml file when we send a new configuration (see bug 1086657). It also should not happen in rhel-7.2 because I changed mutter to ignore the monitors.xml file when we receive a hotplug event. But rhel 7.0 and 7.1 are likely susceptible. Can you verify whether this works on a rhel-7.2 guest?
Comment 5 Bill Sanford 2015-10-07 14:57:33 EDT
Jonathon, why would this work if I have 2 or more displays?
Comment 6 Jonathon Jongsma 2015-10-07 15:10:43 EDT
The way that the gnome display configuration works is that it looks in monitors.xml for an existing saved configuration that has the same displays as you currently have connected. 

Since you had used the guest display control panel to change your resolution to 1440 x 900, monitors.xml now has a saved configuration for a single display. So when you resize that display, mutter gets a hotplug event and knows that it should re-configure the displays. So it looks at the monitors.xml file and finds a configuration for one monitor, so it uses that. 

When you enable a second display, mutter gets another hotplug event, and tries to reconfigure the displays. It now looks in monitors.xml for a saved configuration with 2 displays and doesn't find one. Since there is no saved configuration to apply, it falls back to using the preferred resolution of both displays (which is what we want).

The behavior in rhel-7.2 changes the behavior so that if you are using a QXL device (or really any drm driver that exposes the 'hotplug_mode_update' drm property), it will never try to load a saved configuration from monitors.xml.

If you want to test my theory without trying a rhel-7.2 nightly build, you can simply rename ~/.config/monitors.xml to something else (or delete it) and try to resize the display. It should start working again.
Comment 7 Bill Sanford 2015-10-07 15:56:55 EDT
Works exactly how you said. I will test this on 7.2, shortly and then verify it. Thanks.

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