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:
no pm ack ->revert devel ack to ?
we need to investigate, the problem can be in the client. out of capacity for 3.3 cond nacked
most probably due to some client behaviour, moving there
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
(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
960x720 @ 120% ≃ 800x600 1280x1024 @ 120% ≃ 1067x853
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.
(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.
(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.
closing as not a bug for now, this is by design.
(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?
(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% [-][+] ?
Also users can press ctrl-0 (return to normal zoom) before/after going/returning to/from full-screen mode.
Note: 987549 tracks this rfe.