Bug 864528 - If zooming, and then going to full screen, the resolution of the guest doesn't match the client's resolution
If zooming, and then going to full screen, the resolution of the guest doesn'...
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: mingw-virt-viewer (Show other bugs)
3.1.0
x86_64 Windows
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Marc-Andre Lureau
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-09 10:08 EDT by Vimal Patel
Modified: 2015-09-22 09 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-23 06:54:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vimal Patel 2012-10-09 10:08:27 EDT
Description of problem:
After starting a remote-viewer connection with a guest, not in full screen, then using zoom in or zoom out, and then selecting full screen, the resolution of the guest does not match the clients and there are times when there are black bars at the top and bottom of the screen.

If you just connect with the full screen option, the resolution of the guest always equals the resolution of the client.

Tested using a Win 7 64bit client & guest, with a RHEL6.3 host.

Version-Release number of selected component (if applicable):
Guest:
vdagent-win-0.1-12
qxl-win-unsigned-0.1-15

Client:
mingw64-virt-viewer-0.5.3-11.el6

Host:
qemu-kvm-0.12.1.2-2.320.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.320.el6.x86_64 
qemu-img-0.12.1.2-2.320.el6.x86_64
usbredir-0.5.1-1.el6.x86_64
spice-gtk-python-0.14-2.el6.x86_64  
spice-gtk-0.14-2.el6.x86_64 
spice-glib-0.14-2.el6.x86_64 
spice-client-0.8.2-15.el6.x86_64 
virt-viewer-0.5.2-11.el6.x86_64 
spice-server-0.12.0-1.el6.x86_64 

How reproducible:
Very reproducible.

Steps to Reproduce:
1.  Connect to a guest w/o using -f option  
2.  Use the option View -> Zoom -> Zoom In or Zoom out a couple of times
3.  Go to full screen View -> Full Screen or F11 to go to full screen
  
Actual results:
after selecting the full screen option, the remote viewer window takes the full screen, however the resolution does not match the resolution of the client and there are times where there are black bars at the top and bottom.

Expected results:
after selecting the full screen option, the remote viewer window will take the full screen, and the resolution of the guest will match the resolution of the client.

Additional info:
Comment 1 David Blechter 2013-02-06 13:17:36 EST
no pm ack ->revert devel ack to ?
Comment 2 David Blechter 2013-07-16 09:36:19 EDT
we need to investigate, the problem can be in the client. out of capacity for 3.3
cond nacked
Comment 3 Marc-Andre Lureau 2013-07-16 09:59:12 EDT
most probably due to some client behaviour, moving there
Comment 4 Uri Lublin 2013-07-16 10:52:44 EDT
When the client zooms in/out, its resolution is different than its size.
Upon toggle into full-screen, the size becomes the size of the client screen while the resolution is miscalculated according to the zoom ratio.

The agent receives the wrong resolution and applies it to the guest.

For example (not immediately following in the log file):
zooming (+20%)
  (remote-viewer:9386): DEBUG: Display size request 960x720 (desktop 800x600)
  (remote-viewer:9386): DEBUG: Allocated 960x720
  (remote-viewer:9386): DEBUG: Child allocate 960x720
  (remote-viewer:9386): DEBUG: Display size request 50x50 (desktop 800x600)
  (remote-viewer:9386): DEBUG: Allocated 960x720
  (remote-viewer:9386): DEBUG: Child allocate 960x720
  (remote-viewer:9386): GSpice-DEBUG: #0 +0+0-800x600

toggle into full-screen
  (remote-viewer:9386): DEBUG: Display size request 1280x1024 (desktop 1067x853)
  (remote-viewer:9386): DEBUG: Allocated 1280x1024
  (remote-viewer:9386): DEBUG: Child allocate 1280x1023
  (remote-viewer:9386): DEBUG: Display size request 50x50 (desktop 1067x853)
  (remote-viewer:9386): DEBUG: Allocated 1280x1024
  (remote-viewer:9386): DEBUG: Child allocate 1280x1023
  (remote-viewer:9386): GSpice-DEBUG: #0 +0+0-1067x853
Comment 5 Marc-Andre Lureau 2013-07-22 15:08:29 EDT
(In reply to Uri Lublin from comment #4)
> When the client zooms in/out, its resolution is different than its size.
> Upon toggle into full-screen, the size becomes the size of the client screen
> while the resolution is miscalculated according to the zoom ratio.

What makes you think it is miscalculated?

> The agent receives the wrong resolution and applies it to the guest.
> 
> For example (not immediately following in the log file):
> zooming (+20%)
>   (remote-viewer:9386): DEBUG: Display size request 960x720 (desktop 800x600)
>   (remote-viewer:9386): DEBUG: Allocated 960x720
>   (remote-viewer:9386): DEBUG: Child allocate 960x720
>   (remote-viewer:9386): DEBUG: Display size request 50x50 (desktop 800x600)
>   (remote-viewer:9386): DEBUG: Allocated 960x720
>   (remote-viewer:9386): DEBUG: Child allocate 960x720
>   (remote-viewer:9386): GSpice-DEBUG: #0 +0+0-800x600

That looks about right

> toggle into full-screen
>   (remote-viewer:9386): DEBUG: Display size request 1280x1024 (desktop
> 1067x853)
>   (remote-viewer:9386): DEBUG: Allocated 1280x1024
>   (remote-viewer:9386): DEBUG: Child allocate 1280x1023
>   (remote-viewer:9386): DEBUG: Display size request 50x50 (desktop 1067x853)
>   (remote-viewer:9386): DEBUG: Allocated 1280x1024
>   (remote-viewer:9386): DEBUG: Child allocate 1280x1023
>   (remote-viewer:9386): GSpice-DEBUG: #0 +0+0-1067x853

That too
Comment 6 Marc-Andre Lureau 2013-07-22 15:10:07 EDT
960x720 @ 120% ≃ 800x600
1280x1024 @ 120% ≃ 1067x853
Comment 7 Marc-Andre Lureau 2013-07-22 15:11:51 EDT
Vimal,

I can't reproduce the bug. It is by designed that we keep the zooming ratio even in full screen. Why should we reset it for fullscreen?

If you get black bars, it is most very likely because you are not using a guest agent with arbitrary resolution support. So the guest does a best match., and the client keeps the aspect ration by adding black bars.
Comment 8 Uri Lublin 2013-07-23 02:41:00 EDT
(In reply to Marc-Andre Lureau from comment #5)
> (In reply to Uri Lublin from comment #4)
> > When the client zooms in/out, its resolution is different than its size.
> > Upon toggle into full-screen, the size becomes the size of the client screen
> > while the resolution is miscalculated according to the zoom ratio.
> 
> What makes you think it is miscalculated?

I expected the zoom to reset upon going into full-screen mode, such that the guest resolution matches the client resolution.
Comment 9 Marc-Andre Lureau 2013-07-23 06:53:12 EDT
(In reply to Uri Lublin from comment #8)
> (In reply to Marc-Andre Lureau from comment #5)
> > (In reply to Uri Lublin from comment #4)
> > > When the client zooms in/out, its resolution is different than its size.
> > > Upon toggle into full-screen, the size becomes the size of the client screen
> > > while the resolution is miscalculated according to the zoom ratio.
> > 
> > What makes you think it is miscalculated?
> 
> I expected the zoom to reset upon going into full-screen mode, such that the
> guest resolution matches the client resolution.

I am not convinced we should do this. What is the rationale? It's easy enough for user to reset zoom level to 100%, and it should not surprise him since he set the zoom level before.

Does that mean we should disable zooming entirely in fullscreen? Should we restore the zoom level in window mode? Or have a zooming level for fullscreen and another for window?

I don't think this is worth modifying, it is simpler and less surprising to keep the current behaviour.
Comment 10 Marc-Andre Lureau 2013-07-23 06:54:46 EDT
closing as not a bug for now, this is by design.
Comment 11 Bryan Yount 2013-07-23 18:24:27 EDT
(In reply to Marc-Andre Lureau from comment #10)
> closing as not a bug for now, this is by design.

I would tend to agree with you on this one Marc-Andre. However, don't you think we need a way to force the client to auto-sense again after being in a zoom state? Perhaps a button, like in Firefox if you zoom in, that says "Return to normal zoom" or something?
Comment 12 Marc-Andre Lureau 2013-07-23 21:13:03 EDT
(In reply to Bryan Yount from comment #11)
> (In reply to Marc-Andre Lureau from comment #10)
> > closing as not a bug for now, this is by design.
> 
> I would tend to agree with you on this one Marc-Andre. However, don't you
> think we need a way to force the client to auto-sense again after being in a
> zoom state? Perhaps a button, like in Firefox if you zoom in, that says
> "Return to normal zoom" or something?

I thought the key binding was global, but it isn't. So I sent a patch series for that, so you can still do ctrl-0 even in fullscreen.

Perhaps we need more UI in the toolbar, like a spin button 100% [-][+] ?
Comment 13 Uri Lublin 2013-07-24 05:30:58 EDT
Also users can press ctrl-0 (return to normal zoom) before/after going/returning to/from full-screen mode.
Comment 14 Andrew Cathrow 2013-07-24 08:30:58 EDT
Note: 987549 tracks this rfe.

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