Bug 1309315

Summary: new resolution doesn't take effect after guest reboot
Product: Red Hat Enterprise Linux 8 Reporter: Andrei Stepanov <astepano>
Component: spice-vdagentAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED WONTFIX QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.1CC: astepano, cfergeau, chayang, dblechte, elima, fidencio, jjongsma, juzhang, marcandre.lureau, michen, mkenneth, qzhang, rbalakri, rduda, rstrode, spice-qe-bugs, tpelka, victortoso, virt-maint
Target Milestone: rc   
Target Release: 8.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1130080 Environment:
Last Closed: 2019-05-08 16:21:16 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1130080    
Bug Blocks:    

Comment 2 Andrei Stepanov 2016-02-17 13:15:22 UTC
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 13:20:22 UTC
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 12:26:51 UTC
no solution upstream, moving to 7.4

Comment 5 Jonathon Jongsma 2017-05-26 19:38:00 UTC
(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.

Comment 6 Jonathon Jongsma 2019-05-08 16:21:16 UTC
Honestly, I'm not sure that this should actually be considered a bug. It seems to be at most a minor annoyance. I don't think that rebooting a guest should be considered a common event, so most users will not experience this behavior very often. And the workaround is as simple as resizing the window to the desired size after the reboot. Given the effort that would be required to support this behavior, I don't think it's worth fixing right now.