Bug 728252

Spicec log:

1312466394 INFO [9142:9142] Application::main: starting 0.8.2
1312466394 INFO [9142:9142] init_key_map: using evdev mapping
1312466395 INFO [9142:9142] MultyMonScreen::MultyMonScreen: platform_win: 155189249
1312466395 INFO [9142:9142] Application::enter_full_screen: 
1312466395 INFO [9142:9142] ForeignMenu::ForeignMenu: Creating a foreign menu connection /tmp/SpiceForeignMenu-9142.uds
1312466395 INFO [9142:9143] RedPeer::connect_to_peer: Connect failed: Connection refused (111)
1312466395 INFO [9142:9143] RedPeer::connect_unsecure: Connected to localhost 5900
1312466395 INFO [9142:9146] RedPeer::connect_to_peer: Connect failed: Connection refused (111)
1312466395 INFO [9142:9147] RedPeer::connect_to_peer: Connect failed: Connection refused (111)
1312466395 INFO [9142:9145] RedPeer::connect_to_peer: Connect failed: Connection refused (111)
1312466395 INFO [9142:9147] RedPeer::connect_unsecure: Connected to localhost 5900
1312466395 INFO [9142:9146] RedPeer::connect_unsecure: Connected to localhost 5900
1312466395 INFO [9142:9145] RedPeer::connect_unsecure: Connected to localhost 5900
1312466395 INFO [9142:9148] RedPeer::connect_to_peer: Connect failed: Connection refused (111)
1312466395 INFO [9142:9149] RedPeer::connect_to_peer: Connect failed: Connection refused (111)
1312466395 INFO [9142:9148] RedPeer::connect_unsecure: Connected to localhost 5900
1312466395 INFO [9142:9149] RedPeer::connect_unsecure: Connected to localhost 5900
1312466396 INFO [9142:9143] RedChannel::handle_notify: remote channel 1:0 warn!!! #0: keyboard channel is insecure
1312466403 INFO [9142:9142] DisplayChannel::create_sw_canvas: display 0: using sw

Created attachment 516715 [details]
backtrace of spice client when monitors are "disconnected"

This no longer happens when I revert 419222f0f3

client: fix endless recursion in rearrange_monitors, RHBZ #692976

Changing the Severity, Happened to me with Windows XP guest with stopped agent when migrating.

(In reply to comment #5)
> Changing the Severity, Happened to me with Windows XP guest with stopped agent
> when migrating.

I couldn't reproduce it with RHEL6 x86_64 client with two physical monitors + RHEL 6 guest with an agent running.
Regarding the Windows XP guest, did it have more than one monitor? Might this be related to #695323?

(In reply to comment #6)
> (In reply to comment #5)
> > Changing the Severity, Happened to me with Windows XP guest with stopped agent
> > when migrating.
> 
> I couldn't reproduce it with RHEL6 x86_64 client with two physical monitors +
> RHEL 6 guest with an agent running.
> Regarding the Windows XP guest, did it have more than one monitor? Might this
> be related to #695323?

Noticed two things:
1. Be sure that you are logged in machine.
2. Be sure that your guest resolution before connecting is lower than client's native one.

I am not using Xinerama -> one guest screen only.

Sorry about troubles.

(In reply to comment #6)
> (In reply to comment #5)
> > Changing the Severity, Happened to me with Windows XP guest with stopped agent
> > when migrating.
> 
> I couldn't reproduce it with RHEL6 x86_64 client with two physical monitors +
> RHEL 6 guest with an agent running.
> Regarding the Windows XP guest, did it have more than one monitor? Might this
> be related to #695323?

or please try to change resolution to lower while guest is in full-screen mode with resolution of client.

The resolution change seems to be needed to reproduce this bug.

(In reply to comment #9)
> The resolution change seems to be needed to reproduce this bug.

Yes, sometimes resolution change leads to this same bug, Moreover When I connect to a Guest (with vdagent running) from User Portal resolution of guest is not aligned with client one. I am not sure It is related to this bug, but It might be.

Happing as well when connect to a guest during booting, when switching to a console by Alt+Ctrl+F2.

Looking more into this bug, it happens because of this change:

@@ -1598,7 +1595,15 @@ bool Application::toggle_full_screen()
 
 void Application::resize_screen(RedScreen *screen, int width, int height)
 {
+    Monitor* mon;
+
+    if (_full_screen) {
+        if ((mon = screen->get_monitor())) {
+            mon->set_mode(width, height);
+        }
+    }
     screen->resize(width, height);
+    rearrange_monitors(false, false);
     if (screen->is_out_of_sync()) {
         _out_of_sync = true;
         /* If the client monitor cannot handle the guest resolution

It seems to be happening because mon or screen is never set to the right resolution, thus the screen stays black because the resolution is wrong (?). Moreover, calling rearrange_monitors after screen->resize seems to cause the 
VM display not to be centered properly on the screen.

This patch helps with this bug, but I have no idea whether this causes other regressions, nor if that is the right fix.

diff --git a/client/application.cpp b/client/application.cpp
index 97014f8..a92f143 100644
--- a/client/application.cpp
+++ b/client/application.cpp
@@ -1599,11 +1599,11 @@ void Application::resize_screen(RedScreen *screen, int width, int height)
 
     if (_full_screen) {
         if ((mon = screen->get_monitor())) {
-            mon->set_mode(width, height);
+            mon->set_mode(mon->get_size().x, mon->get_size().y);
+            screen->position_full_screen(mon->get_position());
         }
     }
     screen->resize(width, height);
-    rearrange_monitors(false, false);
     if (screen->is_out_of_sync()) {
         _out_of_sync = true;
         /* If the client monitor cannot handle the guest resolution

(In reply to comment #12)
> Looking more into this bug, it happens because of this change:
> 
> @@ -1598,7 +1595,15 @@ bool Application::toggle_full_screen()
> 
>  void Application::resize_screen(RedScreen *screen, int width, int height)
>  {
> +    Monitor* mon;
> +
> +    if (_full_screen) {
> +        if ((mon = screen->get_monitor())) {
> +            mon->set_mode(width, height);
> +        }
> +    }
>      screen->resize(width, height);
> +    rearrange_monitors(false, false);
>      if (screen->is_out_of_sync()) {
>          _out_of_sync = true;
>          /* If the client monitor cannot handle the guest resolution
> 
> It seems to be happening because mon or screen is never set to the right
> resolution, thus the screen stays black because the resolution is wrong (?).
> Moreover, calling rearrange_monitors after screen->resize seems to cause the 
> VM display not to be centered properly on the screen.
> 
> This patch helps with this bug, but I have no idea whether this causes other
> regressions, nor if that is the right fix.
> 
> diff --git a/client/application.cpp b/client/application.cpp
> index 97014f8..a92f143 100644
> --- a/client/application.cpp
> +++ b/client/application.cpp
> @@ -1599,11 +1599,11 @@ void Application::resize_screen(RedScreen *screen, int
> width, int height)
> 
>      if (_full_screen) {
>          if ((mon = screen->get_monitor())) {
> -            mon->set_mode(width, height);
> +            mon->set_mode(mon->get_size().x, mon->get_size().y);
> +            screen->position_full_screen(mon->get_position());
>          }
>      }
>      screen->resize(width, height);
> -    rearrange_monitors(false, false);
>      if (screen->is_out_of_sync()) {
>          _out_of_sync = true;
>          /* If the client monitor cannot handle the guest resolution
Hi,
when resizing the screen, the monitors mode (resolution) should be set according to the size of the screen (which is the dimension of the corresponding surface). This is what rearrange_monitors does, and it does it for all monitor-screen pairs. So rearrange_monitors should be called, but according to what Christophe found, it should be called before the actual resize takes place. However, since it is not longer called from the Screen class (for avoiding the #692976), and should be called before Screen::resize it should be able to receive sizes as parameter and not only use the Screen::size.
Attached a patch. Still need to test it thoroughly

Created attachment 518183 [details]
possible fix

I tested this patch with master and it's working for me. I can no longer reproduce the bug when using it, and the display is correctly centered when I play with resolution changes. Took me a bit more time than expected to test because I hit yet another fullscreen bug :-/ (screen going black when switching to full screen with a resolution real close to the native LCD resolution)

Btw, I tested with a f15 client and rhel 6.1 guest with agent, and didn't try more than going in and out of fullscreen in various situation, changing resolution a few times.

VERIFIED in spice-client-0.8.2-7

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation needed.

The bug was filed during development and never affected customers.

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-2011-1518.html