Red Hat Bugzilla – Bug 881020
Setting wrong resolution when switching to fullscreen
Last modified: 2013-11-21 01:23:45 EST
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): xorg-x11-drv-qxl-0.1.0-2.el6 spice-vdagent-0.12.0-3.el6 How reproducible: Always 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 Expected results: Each display of a VM should be displayed in it's respective remote-viewer window Additional info: 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 > displays. > > > Version-Release number of selected component (if applicable): > xorg-x11-drv-qxl-0.1.0-2.el6 > spice-vdagent-0.12.0-3.el6 > > How reproducible: > Always 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" host: spice-server-0.12.0-5.el6.x86_64 qemu-kvm-0.12.1.2-2.335.el6.x86_64 client: virt-viewer-0.5.2-16.el6.x86_64 spice-gtk-0.14-4.el6.x86_64 > Works for me switching fullscreen state 10/10 so far with dual-head client & > guest. 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 SPICE_DEBUG=1 virt-viewer
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: virt-viewer-0.5.2-17.el6 Steps: 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 correct. So mark this bug as VERIFIED
(In reply to comment #19) > This bug can be reproduced by following build: > virt-viewer-0.5.2-17.el6 > > Steps: > 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 > correct. > > So mark this bug as VERIFIED Sorry, missed something Verified pass on the following build: virt-viewer-0.5.2-18.el6
There is a similar bug when adding a third display: https://bugzilla.redhat.com/show_bug.cgi?id=886570
Part of the problems discussed here may be fixed by this upstream patch: https://www.redhat.com/archives/virt-tools-list/2013-January/msg00027.html
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: http://cgit.freedesktop.org/spice/linux/vd_agent/commit/?id=4aeb130affbad5bca058a2dc03bd3e41b2b39666 http://cgit.freedesktop.org/spice/linux/vd_agent/commit/?id=dddbaa7db2baed2ec3d509cf97fb9f380e72edb8 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. http://rhn.redhat.com/errata/RHBA-2013-1560.html