While adjusting the guest monitor configuration, the SPICE agent failed to set the resolution when it switched to full-screen mode, because the guests video memory was exhausted. This left the guest monitor configuration in an inconsistent state. This update fixes the issue by reverting the guest monitor configuration to the previous state, when the agent fails to adjust the guest monitor configuration.
Description of problem:
A RHEL6.4 VM can have all the displays rendered/sent in the same remote-viewer window when connecting from a client with multiple physical displays.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Get a client with two physical monitors, each with different resolutions
2. Connect to a RHEL64 VM
3. Open a second display (View -> Displays -> whatever)
4. Click View -> Full screen
Remote viewer will try to render the whole screen in just a single window, the others will be disconnected
Each display of a VM should be displayed in it's respective remote-viewer window
This is an attempt to make bz#865733 a lot cleaner. Check attachments for logs and screencast of what's happening.
*** Bug 865733 has been marked as a duplicate of this bug. ***
(In reply to comment #0)
> Description of problem:
> A RHEL6.4 VM can have all the displays rendered/sent in the same
> remote-viewer window when connecting from a client with multiple physical
> Version-Release number of selected component (if applicable):
> How reproducible:
I have the same guest. What is the host? qemu and spice server version? I could also use the qemu log with "-global qxl-vga.guestdebug=9"
> Steps to Reproduce:
> 1. Get a client with two physical monitors, each with different resolutions
> 2. Connect to a RHEL64 VM
> 3. Open a second display (View -> Displays -> whatever)
> 4. Click View -> Full screen
> 5. Wait
> Actual results:
> Remote viewer will try to render the whole screen in just a single window,
> the others will be disconnected
Works for me switching fullscreen state 10/10 so far with dual-head client & guest.
(In reply to comment #6)
> I have the same guest. What is the host? qemu and spice server version? I
> could also use the qemu log with "-global qxl-vga.guestdebug=9"
> Works for me switching fullscreen state 10/10 so far with dual-head client &
My screens have 1920x1080 and 1680x1050, so what I end up with, is that I have 2 displays with 3600x1080, and centered, lots of borders on all sides...
Wrong resolution also gets set even when setting fullscreen with one window -> it's most likely vdagent or virt-viewer...
I am going to try harder again, in the meantime, try to get the logs of:
qemu "-global qxl-vga.guestdebug=9"
spice-vdagent -dddx log
looks like I changed the title/keywords accidentally
I can reproduce now, and I have a reasonable explanations. For some reasons I failed to reproduce before and lost quite some time :( Working on a fix, ack
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release. Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.
Daniel, please cherry-pick 346f35c87b2631817a2f16be9618f18a98c87567 from upstream. thanks
Created attachment 662417 [details]
When in fullscreen
Created attachment 662419 [details]
When returning from fullscreen
Opening a third display breaks it further.
One display is scaled down
Second one is displayed just as a thin strip
Third one is disconnected, which is ok, however it doesn't reconnect when exiting fullscreen
This bug can be reproduced by following build:
Same as comment 0
1. After switch to full screen, 2nd display works well, and was showed in the 2nd monitor.
2. Both of 2 displays have their own resolutions, and resolutions are correct.
So mark this bug as VERIFIED
(In reply to comment #19)
> This bug can be reproduced by following build:
> Same as comment 0
> Actual result:
> 1. After switch to full screen, 2nd display works well, and was showed in
> the 2nd monitor.
> 2. Both of 2 displays have their own resolutions, and resolutions are
> So mark this bug as VERIFIED
Sorry, missed something
Verified pass on the following build:
There is a similar bug when adding a third display:
Part of the problems discussed here may be fixed by this upstream patch:
I can reproduce this, the problem is not the different size of the monitors, but that a third virtual monitor is active, and when going fullscreen the 3 monitors combined (at their fullscreen resolution) need more video memory then is configured for the qxl device. This means that the agent will get an error from X halfway through setting the new monitor configuration, leaving things in an inconsistent state.
I've just pushed a series of agent patches upstream which causes the agent to fallback to the previous settings if a new set of client monitor-settings cannot be realized, rather then leaving things in an inconsistent state.
With these patches in place, requesting a larger total screen area then fits in the video memory will lead to the following behavior:
1) Going fullscreen with too many / too large monitors:
All virtual monitors stay at their resolution before going fullscreen, and will be scaled to fill the entire screen
2) Maximizing a window with too many / too large monitors:
All virtual monitors stay at their resolution before going fullscreen, and the contents of the maximized window will be scaled to fill the entire window
3) resizing a window to too large dimensions:
The agent will rollback the changes, and the window will snap back to its original size
This is less then ideal, but a lot better as how we behave now, and until we can dynamically adjust the video memory there is not much else we can do.
This is fixed by these 2 commits:
The other 4 commits pushed at the same as those 2 are necessary too, as they do various preparation work for those 2 commits (adding some helper functions, moving some code around).
Moving to post.
This is fixed (as described in comment #35) in spice-vdagent-0.12.0-5.el6, moving to modified.
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.