Description of problem: Remote viewer closes second display after reboot guest which has properly set two displays. Version-Release number of selected component (if applicable): virt-viewer 0.5.3-20.el6ev How reproducible: Always Steps to Reproduce: 1.In user portal (or power user portal) edit Guest to have 2 displays 2.Start Guest, wait for login 3.Click on remote-viewer menu View->Displays and select Display 2 (Display 1 is already selected) 4.Wait for second window open (check display settings on Guest: System->Preferences->Display - there should be two displays) 5.Restart guest (System->Shutdown and restart) Actual results: Second displays window shows only 'Waiting for display 2' until gdm on first display window shows up. Then second display window disappears. Expected results: After restart and gdm start there are two displays like before restart Additional info: Client Windows 7 32b Guest RHEL6.4 64b
With RHEL guest display window close, with Windows guest remain open. Now there is a question what is proper behaviour.
(In reply to comment #1) > With RHEL guest display window close, with Windows guest remain open. > > Now there is a question what is proper behaviour. Not sure why this is set to needinfo from me? I agree that the question is what is proper behavior here, if you're running the client in fullscreen mode, with --full-screen=auto-conf (or the user portal equivalent) then obviously the proper behavior is that after reboot the screen-config of the guest should once more match the screen-config of the client. But when running virt-viewer in windowed mode, I honestly don't know what the best behavior would be.
the simple approach would be to always send client monitor config (auto-conf) when agent is (re-)connected and we are fullscreen (see patch). This is quite trivial to change in virt-viewer, but could have undesirable behaviour in some cases? other approach is to restore monitor config, wasn't the gnome settings daemon supposed to do that already..
Created attachment 714078 [details] 0001-spice-always-send-auto-conf-on-agent-connection.patch
(In reply to comment #4) > the simple approach would be to always send client monitor config > (auto-conf) when agent is (re-)connected and we are fullscreen (see patch). > This is quite trivial to change in virt-viewer, but could have undesirable > behaviour in some cases? I don't see how this can have undesirable behavior as long as we only do it when we're actually fullscreen, but see below. > > other approach is to restore monitor config, wasn't the gnome settings > daemon supposed to do that already.. For connected monitors, yes. But all but the first monitor will only show as connected after being explicitly set connected by the agent, (In reply to comment #5) > Created attachment 714078 [details] > 0001-spice-always-send-auto-conf-on-agent-connection.patch I like, but looking at this I do see 2 problems (both of which already exist prior to the patch). 1) virt_viewer_session_spice_fullscreen_auto_conf only checks for the app's fullscreen-auto-conf property, not if we are actually full-screen when it runs. I believe it should check that and only do its magic if we're actually fullscreen. 2) The size and position virt_viewer_session_spice_fullscreen_auto_conf set later get overridden by calls to spice_main_set_display from virt_viewer_display_spice_size_allocate. This is not really an issue since the value set there should be the same as the ones initially set by virt_viewer_session_spice_fullscreen_auto_conf. But still I believe that virt_viewer_display_spice_size_allocate should check for fullscreen + fullscreen-auto-conf and when that is true not call spice_main_set_display. I was tempted to write here that instead of having virt_viewer_display_spice_size_allocate check fullscreen-auto-conf, we should simply omit the spice_main_set_display call from virt_viewer_session_spice_fullscreen_auto_conf, iow only let virt_viewer_session_spice_fullscreen_auto_conf enable the monitors, and let virt_viewer_display_spice_size_allocate handle the rest but that will lead to disabled monitors first coming up with a default size + a resize a second later, which is not ideal. These 2 can be fixed in a follow up patches, but does seem like something which we should address together with your proposed patch.
Created attachment 714090 [details] PATCH: virt-viewer-display-spice: Skip monitor info in fullscreen-auto-conf mode Thinking about this I saw an easy way to fix problem 2 from my last comment, this patch should do the trick.
(In reply to comment #7) > Created attachment 714090 [details] > PATCH: virt-viewer-display-spice: Skip monitor info in fullscreen-auto-conf > mode > > Thinking about this I saw an easy way to fix problem 2 from my last comment, > this patch should do the trick. It looks like it will prevent changing later the guest monitor resolution in fullscreen, if using auto-conf.
Hi, (In reply to comment #8) > (In reply to comment #7) > > Created attachment 714090 [details] > > PATCH: virt-viewer-display-spice: Skip monitor info in fullscreen-auto-conf > > mode > > > > Thinking about this I saw an easy way to fix problem 2 from my last comment, > > this patch should do the trick. > > It looks like it will prevent changing later the guest monitor resolution in > fullscreen, if using auto-conf. No it won't this is just for sending a size hint to the guest-agent. If you look at virt_viewer_display_spice_size_allocate you will see that it changes auto_resize from AUTO_RESIZE_FULLSCREEN to AUTO_RESIZE_NEVER on the first call iow when we're fullscreen virt_viewer_display_spice_size_allocate only sends the monitor size once, which is actually done to allow the guest to change the resolution without the client immediately generating a monitors-config message with the client monitor size in response, after which the agent will undo the change. So before my patch the situation in fullscreen is: 1) With autoconf monitors-config gets send twice, once by virt_viewer_session_spice_fullscreen_auto_conf and once by virt_viewer_display_spice_size_allocate 2) Without autoconf monitors-config gets sends once by virt_viewer_display_spice_size_allocate After my patch the situation in fullscreen is: 1) With autoconf monitors-config gets send once by virt_viewer_session_spice_fullscreen_auto_conf 2) Without autoconf monitors-config gets sends once by virt_viewer_display_spice_size_allocate Regards, Hans
Hans, I sent updated patch + yours to ML, for review. However, the bug is asking for more, since it's not specific to auto-conf.
Hi, (In reply to comment #10) > Hans, I sent updated patch + yours to ML, for review. Thanks, acked the set on the list. > However, the bug is asking for more, since it's not specific to auto-conf. Well it is mostly asking for what we believe the right thing to-do would be, in auto-conf mode certainly the right thing to-do would be to redo autoconf, as the patches we were discussing do. For non auto-conf mode I think our current behavior is fine, yes it will require the user to re-enable the display after a reboot. But reboots don't happen that often, and who says the user even still wants the second display after a reboot ? So I believe that we should change the Summary to include auto-conf, and move this to post.
with a trivial patch to virt-viewer, we can workaround this problem, patch sent to ML: https://www.redhat.com/archives/virt-tools-list/2013-March/msg00131.html
in mingw-virt-viewer-0.5.3-23.el6ev
*** Bug 928850 has been marked as a duplicate of this bug. ***
*** Bug 928855 has been marked as a duplicate of this bug. ***
regressions caused by that change, working on it
fixes sent to ML: http://lists.freedesktop.org/archives/spice-devel/2013-March/012903.html https://www.redhat.com/archives/virt-tools-list/2013-March/msg00195.html https://www.redhat.com/archives/virt-tools-list/2013-March/msg00196.html
vv dist-git updated
I will verify that I had 4 displays across two monitors and the virt-viewer windows remained open during the reboot and came back as the exact displays I had opened.
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/RHEA-2013-0889.html