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.