Bug 1130080

  Hi,

> Changed default resolution of my rhel6.6 guest, which is 1024x768 in my
> test, to 1440x900 then rebooted it. I found current resolution changed back
> to 1024x768.

Details please.  What exactly have you done?

(In reply to Gerd Hoffmann from comment #2)
>   Hi,
> 
> > Changed default resolution of my rhel6.6 guest, which is 1024x768 in my
> > test, to 1440x900 then rebooted it. I found current resolution changed back
> > to 1024x768.
> 
> Details please.  What exactly have you done?

1. login to guest 

2. 'System' -> 'Preference' -> 'Display', it tells current resolution in guest is 1024x768

3. change currently resolution to other mode like 1440x900, click 'Apply' -> 'Keep This Configuration'

4. reboot in guest

5. login to guest again and repeat step 2 to check current resolution. It tells 1024x768 instead of 1440x900

Ok, I see.  When logging in after reboot I see the display resize to the configured resolution, then quickly switch back to 1024x768.

Turned off spice agent.  Problem disappeared.

So it looks like you are running spice agent, and it is spice-agent which switches the resolution back to 1024x768.  It shouldn't do that IMO, reassigning bug.

Side note: With spice-agent being active there is no need to go through display settings to get a larger screen.  Just resize the virt-viewer window and the guest will adapt automatically.

Damn, bugzilla seems to be hosed, doesn't let me change the component to spice-vdagent.  Reassigning to spice-bugs for now ...

I think this was done more or less by design:

commit 801f10d485c5133cd4d27ee43f2f1bc8307a24b5
Author: Marc-André Lureau <marcandre.lureau>
Date:   Fri Mar 15 20:24:38 2013 +0100

    Update current resolution when agent is started
    
    This ensures we have the requested resolution whenever possible.

However, this is problematic when switching from console to graphical mode or when switching from gdm session (using qxl default resolution 1024x768) to user session.

Solved in spice-vdagent by the commit 9ae51f3702b1fc0d2747e44474c87a818d1e8ec3

spice-vdagent-0.14.0-9.el6.i686

virt-viewer-2.0-1.fc21.x86_64
virt-viewer-2.0-7.el6.x86_64

After reboot&login resolution resets to 1024x768

An easier way to reproduce this bug is by simply logging out and logging in again on the guest.

I found that this bug is actually a regression introduced by the patch proposed as solution for bug 1086657. By reverting that patch, this problem is fixed.

I think the analysis in bug 108665 might be a little off.  Deleting the file is wrong. The file contains user configured setups for the various monitor topologies the user has encountered.  Deleting it will delete not just the current setup, but all setups (granted we're talking about virt here, so there won't be other setups).

Now, enabling or disabling a monitor in virt-viewer is the virtual equivalent of plugging in or unplugging a monitor.  You're interacting with the virtual "hardware" not with the OS, so when that happens the OS should react in the same way it would if a physical monitor was getting plugged in or unplugged.

I think the "change_timestamp < config_timestamp" mention in bug 1086657 is a red herring.  We treat change < config to mean "hot plug happened".  In the case the user "plugs the monitor in" using the virt-viewer UI, we want it to be treated like a hotplug since virt-viewer is modeling hardware.

The display preferences in RHEL6 remembers monitor profiles for the user.  If a user with a laptop docks to their desk monitors, it will remember the config the user set up previously and apply it automatically as soon as it detects the docking. If the user explicitly disables one of the monitors that are plugged in, that monitor will remain disabled next time the user docks.

This same monitor profile logic applies for virtualization setups as well. In bug 1086657 comment 0 step 4, the reporter is doing exactly that: turning the monitor off in the profile.  Next time the explicitly disabled monitor is "plugged in" (using virt-viewer) it won't be turned on automatically, precisely because the user told it to stay off.

What is weird behavior is bug 1086657 comment 6: that disabling the monitor in the rhel6 display preferences makes it show up as disconnected in xrandr output.  If you turn a monitor off using the OS display preferences, it should still show as connected (plugged in) ! So that's probably a root bug, or at least the first bug that needs to get addressed.  Turning a monitor off in the OS, shouldn't make the virtual plug fall off the virtual connector.

to be clear, I think the "unlink monitors.xml" behavior should be reverted.

(In reply to Ray Strode [halfline] from comment #15)
> to be clear, I think the "unlink monitors.xml" behavior should be reverted.

I think #1086657 could really use your help if it's reopened.

(In reply to Ray Strode [halfline] from comment #15)
> to be clear, I think the "unlink monitors.xml" behavior should be reverted.


By the way, this "unlink monitors.xml" behavior was a workaround for rhel6 only. In rhel7/upstream, it's handled differently (though you might still consider it wrong). 

The relevant commit is here: https://git.gnome.org/browse/mutter/commit/?id=7012c82fc7ac1ff5f2d6ef12d2e6e01b2bef9472

Basically, if the X driver has the 'hotplug_mode_update' property (which is basically only the QXL driver at this point), mutter will simply ignore the monitors.xml file and never try to load configurations from it. This avoids the "need" to remove this file, though it results in the same basic behavior.

The reason we chose this approach is because even though adding a new virtual monitor is analogous to plugging in a new physical monitor, there are some important differences:

- a physical machine can get a new monitor as a side-effect of another action such as docking a laptop. When the user plugs the laptop into a dock, she usually has the setup configured in a certain way and wants this configuration to be restored. On the other hand, we only ever get a new virtual monitor by explicitly enabling the monitor in virt-viewer (which sends a "monitors config" message to the spice server). I think it would be a pretty unexpected (and a poor user experience) if, when the user enables a display in virt-viewer, the guest chose not to enable this display due to a previously stored configuration and required the user to open the gnome display configuration utility to enable it from within the guest.

- monitors.xml basically assumes that a given monitor will always support the mode that is stored in the monitors.xml file. For physical monitors, this is basically true because they support a fixed set of modes. For virtual monitors, this is not the case. Due to how the QXL driver is implemented, a virtual monitor always supports a set of standard modes (800x600, 1280x720, etc), and possibly a single arbitrary mode that has been configured via spice (for example, 1463x1056). If we store this 1463x1056 mode in the config file and then resize the virt-viewer window (to e.g. 1234x987), virt-viewer will send a monitors-config message down to the spice server, which will update the device such that it now supports the standard modes and also 1234x987. 1463x1056 is no longer a supported mode, so even if we tried to retain the user's saved configuration, we would not be able to. The "hardware" no longer supports that mode. 

For these reasons (and possibly others that I can't remember at the moment), we chose to bypass the saved configuration infrastructure for devices with "hotplug_mode_update". If you have ideas on ways to handle this better, I'd be happy to hear them, but I haven't been able to come up with anything better yet.

Your comment about the disabled monitor becoming disconnected is probably true -- that may be a bug in QXL. But the above issues would still remain even if this was changed.

spice-vdagent-0.14.0-11.el6.i686

virt-viewer-2.0-13.el6.x86_64 & virt-viewer-2.0-6.el7.x86_64

# ps axwu | grep spice-vdagent
root      2043  0.0  0.0   3640   824 ?        Ss   12:58   0:00 /usr/sbin/spice-vdagentd
gdm       2514  0.0  0.0   5544  1344 ?        Ss   12:58   0:00 /usr/bin/spice-vdagent
astepano  2695  0.0  0.0   5544  1428 ?        Ss   12:58   0:00 /usr/bin/spice-vdagent


After reboot&login resolution resets to 1024x768

There are several ways to change GuestOS's resolution:

1. Using 'System' -> 'Preference' -> 'Display' at GuestOS.
2. Pulling remote-viewer's window borders.
3. etc...

For the current fix, it is true that:

Changes at "Display Settings" can survive GuestOS reboot. After login to VM resolution becomes as it was before to reboot. 

But, there is a problem : Another methods for changing resolution do not survive after VM reboot. For example, if you pull remote-viewer window to set custom resolution, it resets to 1024x768 after VM reboot.

There are few questions to the reporter: Chao Yang, what is your test case? What is priority for this bug? Are you satisfied with current solution?

(In reply to Andrei Stepanov from comment #20)
> There are several ways to change GuestOS's resolution:
> 
> 1. Using 'System' -> 'Preference' -> 'Display' at GuestOS.
> 2. Pulling remote-viewer's window borders.
> 3. etc...
> 
> For the current fix, it is true that:
> 
> Changes at "Display Settings" can survive GuestOS reboot. After login to VM
> resolution becomes as it was before to reboot. 
> 
> But, there is a problem : Another methods for changing resolution do not
> survive after VM reboot. For example, if you pull remote-viewer window to
> set custom resolution, it resets to 1024x768 after VM reboot.
> 
> There are few questions to the reporter: Chao Yang, what is your test case?
> What is priority for this bug? Are you satisfied with current solution?

Yes, it is ok to me if this behavior is expected.

Andrei, is the confirmation from the comment 21 enough to verify the bug? 

Steps to reproduce are described in the comment 3

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-0950.html