Bug 1249469 - The resolution cannot adjust automatically after virt-viewer window size changed
The resolution cannot adjust automatically after virt-viewer window size changed
Status: CLOSED DUPLICATE of bug 1166319
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: virt-viewer (Show other bugs)
7.2
x86_64 Unspecified
medium Severity medium
: rc
: ---
Assigned To: Virt Viewer Maint
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-03 01:40 EDT by xiaodwan
Modified: 2015-08-04 23:09 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-04 11:16:52 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 xiaodwan 2015-08-03 01:40:53 EDT
Description of problem:
The resolution cannot adjust automatically after virt-viewer window size changed.

Version-Release number of selected component (if applicable):
virt-viewer-2.0-5.el7.x86_64

Package version in Guest.
spice-vdagent-0.14.0-9.el7.x86_64


How reproducible:
100%

Steps to Reproduce:
1. Prepare a RHEL7 guest(I tested it in RHEL7.1), make sure spice-vdagentd service is active), make sure the resolution can adjust automatically when drag the virt-viewer window by mouse.
2. Run "virt-viewer $guest -f" to open the guest in fullscreen mode and the resolution is changed to correct resolution automatically.
3. Set the resolution to a fixed value, such as 1280x1024.
4. Leave fullscreen and close it.
5. Run "virt-viewer $Guest" to open the guest again, drag the virt-viewer window by mouse.

Actual result:
The resolution cannot adjust with the window size automatically.

Expected result:
The resolution should be adjusted with the window size automatically.

Additional information:
This issue doesn't occur with RHLE6.7 guest.
Comment 2 David Blechter 2015-08-03 07:29:47 EDT
(In reply to xiaodwan from comment #0)
> Description of problem:
> The resolution cannot adjust automatically after virt-viewer window size
> changed.
> 
> Version-Release number of selected component (if applicable):
> virt-viewer-2.0-5.el7.x86_64
> 
> Package version in Guest.
> spice-vdagent-0.14.0-9.el7.x86_64
> 
> 
> How reproducible:
> 100%
> 
> Steps to Reproduce:
> 1. Prepare a RHEL7 guest(I tested it in RHEL7.1), make sure spice-vdagentd
> service is active), make sure the resolution can adjust automatically when
> drag the virt-viewer window by mouse.
> 2. Run "virt-viewer $guest -f" to open the guest in fullscreen mode and the
> resolution is changed to correct resolution automatically.
> 3. Set the resolution to a fixed value, such as 1280x1024.
> 4. Leave fullscreen and close it.
> 5. Run "virt-viewer $Guest" to open the guest again, drag the virt-viewer
> window by mouse.
> 
> Actual result:
> The resolution cannot adjust with the window size automatically.

What is the client display resolution, and what exact resolution the windows is set to in both cases ( rhel 7.1 and rhel 6.7 guests )?


> 
> Expected result:
> The resolution should be adjusted with the window size automatically.
> 
> Additional information:
> This issue doesn't occur with RHLE6.7 guest.

Are you running the same virt-viewer to connect to both rhel 7.1 and rhel 6.7 guests? Is virt-viewer running on rhel 7.2 client?
Comment 3 xiaodwan 2015-08-04 04:11:53 EDT
(In reply to David Blechter from comment #2)
> (In reply to xiaodwan from comment #0)
> > Description of problem:
> > The resolution cannot adjust automatically after virt-viewer window size
> > changed.
> > 
> > Version-Release number of selected component (if applicable):
> > virt-viewer-2.0-5.el7.x86_64
> > 
> > Package version in Guest.
> > spice-vdagent-0.14.0-9.el7.x86_64
> > 
> > 
> > How reproducible:
> > 100%
> > 
> > Steps to Reproduce:
> > 1. Prepare a RHEL7 guest(I tested it in RHEL7.1), make sure spice-vdagentd
> > service is active), make sure the resolution can adjust automatically when
> > drag the virt-viewer window by mouse.
> > 2. Run "virt-viewer $guest -f" to open the guest in fullscreen mode and the
> > resolution is changed to correct resolution automatically.
> > 3. Set the resolution to a fixed value, such as 1280x1024.
> > 4. Leave fullscreen and close it.
> > 5. Run "virt-viewer $Guest" to open the guest again, drag the virt-viewer
> > window by mouse.
> > 
> > Actual result:
> > The resolution cannot adjust with the window size automatically.
> 
> What is the client display resolution, and what exact resolution the windows
> is set to in both cases ( rhel 7.1 and rhel 6.7 guests )?
> 

After run "virt-viewer rhel7.1 -f", the resolution of the guest is set to 1920x1080, which is consistent with my physical monitor. And then modify it to a fixed value, such as 1440x900, and click Apply in Guest. Now the resolution is changed to 1440x900. Leave the fullscreen and drag the virt-viewer window to change its size by mouse.

When do the same operation in RHEL6.7, after leaving fullscreen, the resolution changed from 1440x900(i set it manually from 1920x1080) to 1920x1051 (This resolution is auto set with the virt-viewer window size).

> 
> > 
> > Expected result:
> > The resolution should be adjusted with the window size automatically.
> > 
> > Additional information:
> > This issue doesn't occur with RHLE6.7 guest.
> 
> Are you running the same virt-viewer to connect to both rhel 7.1 and rhel
> 6.7 guests? Is virt-viewer running on rhel 7.2 client?

Yes, the same virt-viewer. I updated all the packages based on the tree "http://download.englab.nay.redhat.com/pub/rhel/rel-eng/RHEL-7.2-20150720.0/".
Comment 4 Jonathon Jongsma 2015-08-04 11:13:27 EDT
This is roughly the same problem as Bug 1086657. When you change a resolution from the guest's control panel, it saves that configuration in ~/.config/monitors.xml. Then when there is a hotplug event, gnome-settings-daemon will try to reconfigure the displays. It will try to find a stored configuration that matches the current displays. In this case, it finds a valid 1-monitor configuration and uses that (on the assumption that the user has explicitly configured that resolution in the past, so it's probably the one that the user wants). 

This should be fixed upstream in mutter. The approach taken is that if the output has a "hotplug_mode_update" property, then we will not attempt to use a stored configuration, but instead makes a default configuration using the preferred resolution for each display.

This bug should be fixed in RHEL-7.2 since these changes were backported in Bug 1166319. However, RHEL7.1 guests will still exhibit this bug.
Comment 5 Jonathon Jongsma 2015-08-04 11:16:52 EDT

*** This bug has been marked as a duplicate of bug 1166319 ***
Comment 6 xiaodwan 2015-08-04 23:09:17 EDT
(In reply to Jonathon Jongsma from comment #4)
> This is roughly the same problem as Bug 1086657. When you change a

Bug 1086657 is a RHEL6 issue, not occur in RHLE7 and it has already been fixed. So i'm a little confused for saying same with 1086657. And In this issue, RHEL6 guest is normal.

> resolution from the guest's control panel, it saves that configuration in
> ~/.config/monitors.xml. Then when there is a hotplug event,
> gnome-settings-daemon will try to reconfigure the displays. It will try to
> find a stored configuration that matches the current displays. In this case,
> it finds a valid 1-monitor configuration and uses that (on the assumption
> that the user has explicitly configured that resolution in the past, so it's
> probably the one that the user wants). 
> 
> This should be fixed upstream in mutter. The approach taken is that if the
> output has a "hotplug_mode_update" property, then we will not attempt to use
> a stored configuration, but instead makes a default configuration using the
> preferred resolution for each display.
> 
> This bug should be fixed in RHEL-7.2 since these changes were backported in
> Bug 1166319. However, RHEL7.1 guests will still exhibit this bug.


I tested in RHLE7.2 guest and didn't met this issue, so i think bug 1166319 is fixed. This issue only met in RHEL7.1 guest. Will this issue for RHEL7.1 guest be fixed? If yes, It should not be a duplicate issue. If no, it should be wontfix.

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