(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?

(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/".

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.

*** This bug has been marked as a duplicate of bug 1166319 ***

(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.