Bug 728252 - --full-screen option of spice client does not work
Summary: --full-screen option of spice client does not work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-client
Version: 6.2
Hardware: Unspecified
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Yonit Halperin
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks: 733881 743047
TreeView+ depends on / blocked
 
Reported: 2011-08-04 14:01 UTC by Marian Krcmarik
Modified: 2011-12-06 15:28 UTC (History)
8 users (show)

Fixed In Version: spice-client-0.8.2-5.el6
Doc Type: Bug Fix
Doc Text:
No documentation needed. The bug was filed during development and never affected customers.
Clone Of:
: 733881 (view as bug list)
Environment:
Last Closed: 2011-12-06 15:28:24 UTC


Attachments (Terms of Use)
backtrace of spice client when monitors are "disconnected" (5.35 KB, text/plain)
2011-08-04 14:04 UTC, Marian Krcmarik
no flags Details
possible fix (4.23 KB, patch)
2011-08-14 12:30 UTC, Yonit Halperin
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1518 normal SHIPPED_LIVE libcacard and spice-client bug fix and enhancement update 2011-12-06 00:50:43 UTC

Description Marian Krcmarik 2011-08-04 14:01:47 UTC
Description of problem:
Client results in blank screen (like no signal received by monitors) when connecting to a RHEL guest with --full-screen option (i.e. spicec -h $host -p $port --full-screen). 
This does not happen with older spice-client (0.8.0-2). It happens only against RHEL guest with spice-vdagent running.

Version-Release number of selected component (if applicable):
spice-client 0.8.2-2

How reproducible:
Always

Steps to Reproduce:
1. Connect to a RHEL guest using "spicec -h $host -p $port --full-screen"
  
Actual results:
Blank screen - disconnected monitors

Expected results:
Guest dipslay in full-screen

Additional info:
I am using dual monitor.

Comment 1 Marian Krcmarik 2011-08-04 14:02:44 UTC
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

Comment 2 Marian Krcmarik 2011-08-04 14:04:51 UTC
Created attachment 516715 [details]
backtrace of spice client when monitors are "disconnected"

Comment 4 Christophe Fergeau 2011-08-05 10:11:55 UTC
This no longer happens when I revert 419222f0f3

client: fix endless recursion in rearrange_monitors, RHBZ #692976

Comment 5 Marian Krcmarik 2011-08-05 17:20:48 UTC
Changing the Severity, Happened to me with Windows XP guest with stopped agent when migrating.

Comment 6 Yonit Halperin 2011-08-07 09:24:57 UTC
(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?

Comment 7 Marian Krcmarik 2011-08-07 18:03:35 UTC
(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.

Comment 8 Marian Krcmarik 2011-08-07 20:28:54 UTC
(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.

Comment 9 Christophe Fergeau 2011-08-08 08:13:18 UTC
The resolution change seems to be needed to reproduce this bug.

Comment 10 Marian Krcmarik 2011-08-09 15:33:42 UTC
(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.

Comment 11 Marian Krcmarik 2011-08-09 15:52:03 UTC
Happing as well when connect to a guest during booting, when switching to a console by Alt+Ctrl+F2.

Comment 12 Christophe Fergeau 2011-08-10 10:03:36 UTC
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

Comment 13 Yonit Halperin 2011-08-14 12:29:12 UTC
(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

Comment 14 Yonit Halperin 2011-08-14 12:30:09 UTC
Created attachment 518183 [details]
possible fix

Comment 15 Christophe Fergeau 2011-08-15 15:10:40 UTC
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)

Comment 16 Christophe Fergeau 2011-08-15 15:11:39 UTC
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.

Comment 19 David Jaša 2011-10-14 15:24:40 UTC
VERIFIED in spice-client-0.8.2-7

Comment 20 Uri Lublin 2011-11-21 16:36:17 UTC
    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.

Comment 21 errata-xmlrpc 2011-12-06 15:28:24 UTC
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


Note You need to log in before you can comment on or make changes to this bug.