Bug 805146 - Size of remote-viewer window is too small after switching off full-screen
Size of remote-viewer window is too small after switching off full-screen
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.3
Unspecified Unspecified
high Severity high
: rc
: ---
Assigned To: Marc-Andre Lureau
Virtualization Bugs
:
Depends On:
Blocks: 835616 1009648 916810 921332
  Show dependency treegraph
 
Reported: 2012-03-20 11:37 EDT by Marian Krcmarik
Modified: 2016-04-26 12:44 EDT (History)
15 users (show)

See Also:
Fixed In Version: virt-viewer-0.6.0-1.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 916810 921332 (view as bug list)
Environment:
Last Closed: 2014-10-14 02:28:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Window after full-screen off (1.13 MB, image/png)
2012-03-20 11:38 EDT, Marian Krcmarik
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 321953 None None None Never

  None (edit)
Description Marian Krcmarik 2012-03-20 11:37:31 EDT
Description of problem:
Size of remote-viewer window is too small after switching off full-screen, Once an user connect to a guest using -f option and switches off full-screen, Resolution of guest remains to be same as It was in full-screen but remote-viewer window is really small - see attached image.
I am not sure where to file that - spice-gtk or virt-viewer

Version-Release number of selected component (if applicable):
virt-viewer-0.5.2-1.el6.x86_64
spice-gtk-0.11-1.el6.x86_64
spice-xpi-2.7-11.el6.x86_64
spice-protocol-0.10.1-1.el6.noarch
spice-glib-0.11-1.el6.x86_64
spice-gtk-tools-0.11-1.el6.x86_64

How reproducible:
always

Steps to Reproduce:
1. Connect to a guest with remote-viewer spice://$host?port=$port -f
2. Switch off full-screen
  
Actual results:
See attached image

Expected results:
Size of Window should be mathcing the one as remote viewer would be connected to guest without using -f option -> window matching full-screen resolution.

Additional info:
Comment 1 Marian Krcmarik 2012-03-20 11:38:26 EDT
Created attachment 571453 [details]
Window after full-screen off
Comment 2 Marc-Andre Lureau 2012-03-20 11:50:50 EDT
(In reply to comment #0)
> Expected results:
> Size of Window should be mathcing the one as remote viewer would be connected
> to guest without using -f option -> window matching full-screen resolution.

I could open a bug to suggest the other way around, it's really incovenient to have a big window, especially when you can't resize it like spicec. If you want no scaling, you can press Control-0, which resets the scaling.

So what is the issue in reality? The desktop is scaled too small by default in window mode? It's not usable. The bug seems to be that the Spice Windows agent doesn't resize correctly the guest to the best matching resolution. If the agent is not running, then what should we do?
Comment 4 Marian Krcmarik 2012-03-20 12:20:10 EDT
(In reply to comment #2)
> (In reply to comment #0)
> > Expected results:
> > Size of Window should be mathcing the one as remote viewer would be connected
> > to guest without using -f option -> window matching full-screen resolution.
> 
> I could open a bug to suggest the other way around, it's really incovenient to
> have a big window, especially when you can't resize it like spicec. If you want
> no scaling, you can press Control-0, which resets the scaling.
Ctrl+0 keyboard shortcut does not work for me (it works when triggered in Menu). It's even worse to get such small window than to get the big window with client resolution. I can hardly see what inside guest is.
> 
> So what is the issue in reality? The desktop is scaled too small by default in
> window mode? It's not usable. The bug seems to be that the Spice Windows agent
> doesn't resize correctly the guest to the best matching resolution. If the
> agent is not running, then what should we do?

It happens the same with Windows or RHEL guests -> both agents, it seems that agents are working properly, just The resolution change is not triggered somehow? Maybe because the window is too small, too far away from any available resolution?

Summarize:
- If keyboard shortcut Ctrl+0 does not work - It would be nice to fix.
- The remote-viewer window  after switching off full-screen could be at least of size 640x480
- Resolution change of guest should be triggered to match the size of window even the window is too small or too far away from possible range, in general I can see that sometimes if size of remote-viewer is not close to available resolution, scaling does not happen?
Comment 5 David Jaša 2012-03-20 12:20:35 EDT
That depends mainly on usage of the VM - if only small or maximized windows are used, I'd prefer having the screen size of the VM shrinked to some sensible size that will fit nicely to the client desktop. OTOH, when large-but-not-maximized windows are used, resolution change will break their geometry so I'd rather bite the bulled and keep the client window larger than client screen.

Display scaling should be avoided IMO if possible, especially scaling of 1600 x 900 guest to fit into 404x427 window (like the one already attached by Marian).
Comment 6 Daniel Berrange 2012-04-03 13:39:06 EDT
> So what is the issue in reality? The desktop is scaled too small by default in
> window mode? It's not usable. The bug seems to be that the Spice Windows agent
> doesn't resize correctly the guest to the best matching resolution. If the
> agent is not running, then what should we do?

The problem is this

 - Start virt-viewer normally, display comes up at the current guest res (640x480)
 - Start virt-viewer with --full-screen, display comes up fullscree. Leave fullscreen, and the display is now 400x400. It should be 640x480, ie the same res it would have started with, if --full-screen was not given.

The same applies for both SPICE without a guest agent, and VNC.
Comment 9 RHEL Product and Program Management 2012-07-10 04:49:58 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 10 RHEL Product and Program Management 2012-07-10 22:00:36 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 14 Bryan Yount 2013-02-28 20:16:35 EST
Raising severity to High due to the customer impact. Cloning to mingw-virt-viewer.
Comment 16 Marc-Andre Lureau 2013-05-08 10:15:39 EDT
This was fixed with bug https://bugzilla.redhat.com/show_bug.cgi?id=916810
Comment 23 CongDong 2013-07-03 07:44:10 EDT
I can reproduce this bug:

version:

# rpm -qa virt-viewer
virt-viewer-0.5.2-18.el6_4.2.x86_64

# rpm -qa | grep spice
spice-gtk-0.20-1.el6.x86_64
spice-server-0.12.3-1.el6.x86_64
spice-vdagent-0.14.0-1.el6.x86_64
spice-gtk-python-0.20-1.el6.x86_64
spice-xpi-2.7-22.el6.x86_64
spice-client-0.8.2-15.el6.x86_64
spice-glib-0.20-1.el6.x86_64
spice-protocol-0.12.2-1.el6.noarch

Steps:
1. # virsh start T1
2. # remote-viewer spice://127.0.0.1:5900 -f
3. Click "Leave Fullscreen"

Result:
The guest window is small, same with the attached image.

Try to verify:
version:
# rpm -qa virt-viewer
virt-viewer-0.5.6-1.el6.x86_64
# rpm -qa virt-viewer
virt-viewer-0.5.6-1.el6.x86_64
[root@KP-T2 new]# rpm -qa |grep spice
spice-gtk-0.20-1.el6.x86_64
spice-server-0.12.3-1.el6.x86_64
spice-vdagent-0.14.0-1.el6.x86_64
spice-gtk-python-0.20-1.el6.x86_64
spice-xpi-2.7-22.el6.x86_64
spice-client-0.8.2-15.el6.x86_64
spice-glib-0.20-1.el6.x86_64
spice-protocol-0.12.2-1.el6.noarch

Steps:
As the steps above.

Result:
The guest window is small, same with the attached image.

As the result, can't verified this bug
Comment 24 Marc-Andre Lureau 2013-11-04 11:28:54 EST
For different reasons, it is fixed in upstream since 34bbb27 (cherry-picking this and a few related commits is not enough)

I suggest we wait until a rebase (probably 0.5.8).
Comment 25 Marc-Andre Lureau 2014-06-04 12:20:55 EDT
moving to 6.6
Comment 27 CongDong 2014-06-09 03:53:38 EDT
I can reproduce this with:
virt-viewer-0.5.2-18.el6_4.2.x86_64

Verify:
Steps:
1. prepare a spice rhel guest and configure its resolution to 640*480
2. connect the guest with remote-viewer
# remote-viewer spice://$ip:$port -f
3. Click "Leave fullscreen" button

Result:
Step3, after leave fullscreen, the guest changed to windowed mode, the resolution is 1680*1025, the resolution of my physical monitor is 1680*1050.

As the description and comment 6, I think after leave fullscreen, the resolution of guest should be 640*480, so do you think my result is expected?
Comment 28 CongDong 2014-07-06 23:11:05 EDT
Retest with virt-viewer-0.6.0-9.el6.x86_64
Still got same problem with comment 27, so ASSIGNED
Comment 29 Marc-Andre Lureau 2014-07-07 06:09:30 EDT
(In reply to CongDong from comment #27)
> Result:
> Step3, after leave fullscreen, the guest changed to windowed mode, the
> resolution is 1680*1025, the resolution of my physical monitor is 1680*1050.

> As the description and comment 6, I think after leave fullscreen, the
> resolution of guest should be 640*480, so do you think my result is expected?

It should keep the current resolution, while still fitting the display to be fully visible in window mode, so that is expected
Comment 30 CongDong 2014-07-07 22:25:47 EDT
As comment 27 and comment 28, set VERIFIED.
Comment 31 errata-xmlrpc 2014-10-14 02:28:51 EDT
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-2014-1379.html

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