Bug 1309315 - new resolution doesn't take effect after guest reboot
new resolution doesn't take effect after guest reboot
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: spice-vdagent (Show other bugs)
7.3
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Default Assignee for SPICE Bugs
SPICE QE bug list
:
Depends On: 1130080
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-17 07:53 EST by Andrei Stepanov
Modified: 2017-06-05 12:02 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1130080
Environment:
Last Closed:
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)
Comment 2 Andrei Stepanov 2016-02-17 08:15:22 EST
The original bug was fixed only in half way. To be exact, display resolution can survive VM reboot only that was set in "Display Preferences" dialogue. There are other ways to set VM resolution. One of them is pulling borders of virt-viewer window. Just resize the virt-viewer window and the guest will adapt automatically. In this case resolution doesn't survive VM reboot and resets to 1024x768.

Steps to reproduce:

1. Login to guest 
2. Pull remote-viewer border to setup arbitrary resolution in VM.
3. Reboot in guest
4. Login to guest again 
5. Check current resolution. (xrand) It tells 1024x768 instead of from step #2.
Comment 3 Pavel Grunt 2016-03-11 08:20:22 EST
resolution changes are not handled by the agent. Fix will have to go to a component which is aware of the changes
Comment 4 Pavel Grunt 2016-08-17 08:26:51 EDT
no solution upstream, moving to 7.4
Comment 5 Jonathon Jongsma 2017-05-26 15:38:00 EDT
(In reply to Andrei Stepanov from comment #2)
> The original bug was fixed only in half way. To be exact, display resolution
> can survive VM reboot only that was set in "Display Preferences" dialogue.
> There are other ways to set VM resolution. One of them is pulling borders of
> virt-viewer window. Just resize the virt-viewer window and the guest will
> adapt automatically. In this case resolution doesn't survive VM reboot and
> resets to 1024x768.
> 
> Steps to reproduce:
> 
> 1. Login to guest 
> 2. Pull remote-viewer border to setup arbitrary resolution in VM.
> 3. Reboot in guest
> 4. Login to guest again 
> 5. Check current resolution. (xrand) It tells 1024x768 instead of from step
> #2.

So, this is related to the issue discussed by myself and Ray Strode above (see bug 1130080 comment 17). In order to ensure that arbitrary resizing works properly, when the graphics driver supports hotplug_mode_update property the desktop will bypass the monitors.xml configuration file and always set the resolution to the preferred resolution of the driver. As Ray argued above, this could be considered 'incorrect' behavior, but the alternative is that resizing from the client will not work properly. 

What is happening is this:

- user resizes their client to some arbitrary size (let's say 1234x912)
  - 1234x912 is now the preferred resolution of the driver. 
  - Even if the desktop already has a configuration for this display (monitors.xml), it will be ignored
  - the desktop sets the resolution to the preferred mode of the driver (1234x912)
- user reboots guest
  - during shutdown, the QXL driver gets unloaded so the driver no longer "remembers" its preferred mode of 1234x912.
  - guest switches to text mode and the display is resized to something like 800x600
  - The client window also gets resized to match
  - After reboot, the qxl driver gets reloaded and it comes up using its default resolution (e.g. 1024x768)

I believe that this problem did not exist in the past, but started appearing after qemu made a change that unloaded the QXL driver during reboot (the same root cause as Bug 1274447). Before that change, it's possible that the QXL device maintained the same preferred resolution through the reboot and therefore that resolution was restored after reboot.


The only real option that I can think of for fixing this behavior is for the desktop to restore the resolution after re-logging into gnome. Restoring the configuration from monitors.xml is the normal way to achieve this. But A) arbitrary resolutions configured via the spice client are not written to monitors.xml, and B) we currently bypass this functionality since it interferes with arbitrary resizing via the client. So fixing this will not be trivial, I fear.

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