Red Hat Bugzilla – Bug 993789
Executing xrandr reverts previous resolution change
Last modified: 2015-10-27 20:19:49 EDT
Description of problem:
After changing resolution of guest system in remote-viewer using xrandr and running xrandr command again afterwards, the resolution is reverted back to the previous one. According to xrandr output, the resolution is still the same as set previously.
Version-Release number of selected component (if applicable):
Host & client: RHEL 7
Fedora 19: spice-vdagent-0.14.0-2.fc19.x86_64
RHEL 7: spice-vdagent-0.14.0-3.el7.x86_64
Steps to Reproduce:
1. make sure spice-vdagent service is running in guest (resolution is 1024x768)
2. execute 'xrandr -s 640x480'
3. execute 'xrandr' to trigger the resolution reversion (with RHEL7 guest this step is not needed)
Guest screen resolution changes back from 640x480 to 1024x768, even though xrandr output states the actual resolution is still 640x480.
Guest screen resolution stays the same as set.
Created attachment 783302 [details]
remote-viewer --spice-debug log
Created attachment 783303 [details]
This is a problem with the new kms driver, where the agent is no longer involved in the display resizing path. I've done some testing and it seems that monitor changes don't get seen by the guest (by gnome-settings-daemon?) until xrandr is run.
IE if you fullscreen the client window then running xrandr from a terminal will actually resize the guest to the fullscreen resolution, where one would expect the resize to happen immediately upon going fullscreen (tested with a fully up2date F-19).
It seems that using kms also sometimes causes empty monitor config info to the client, ie during my F-19 tests I get various messages like these:
(remote-viewer:14603): GSpice-CRITICAL **: display_handle_monitors_config: assertion 'config->count > 0' failed
This doesn't reproduce for me with a RHEL 7 Beta 1 guest and host.
Is this still reproducible?
In RHEL7 Beta1, I couldn't reproduce. However, the warning message as reported by Hans is still being printed.
I have filed
to track the warning message.
Closing this bug since it isn't reproducible any more.