Bug 1054757 - SPICE console is always scaled in fullscreen mode even if "Automatically resize" is disabled.
Summary: SPICE console is always scaled in fullscreen mode even if "Automatically resi...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: spice-gtk
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Marc-Andre Lureau
QA Contact: Desktop QE
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 1009648 1067346
TreeView+ depends on / blocked
 
Reported: 2014-01-17 12:29 UTC by François Cami
Modified: 2014-10-14 06:46 UTC (History)
17 users (show)

(edit)
Cause: "Resizing" and "Scaling" a display are rather similar terms. Virt-viewer / remote-viewer always scales displays (zooms the display on the client to fit the local window size), but allowed the user to disable resizing of the display (changing the resolution on the guest to match the display window size)

Consequence: Users get confused and sometimes expect different behavior.

Fix: Remove the ability for user to disable resizing.

Result: virt-viewer will always automatically change the resolution on the guest to match the window size if possible.
Clone Of:
: 1067346 (view as bug list)
(edit)
Last Closed: 2014-10-14 06:46:56 UTC


Attachments (Terms of Use)
0001-cairo-disable-scaling-if-SPICE_NOSCALE.patch (1.09 KB, patch)
2014-06-05 19:28 UTC, Marc-Andre Lureau
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1487 normal SHIPPED_LIVE spice-gtk bug fix and enhancement update 2014-10-14 01:28:31 UTC

Description François Cami 2014-01-17 12:29:53 UTC
Description of problem:
When the virt-viewer "Automatically resize" checkbox is OFF and "Fullscreen" mode is selected, the display is resized anyway.
That means that on a native 2048x2048 physical screen displaying a 2000x2000 SPICE client, going to fullscreen results in tearing due to non-native resolution.

Version-Release number of selected component (if applicable):
spice-gtk-0.20-11
virt-viewer-0.5.6-8.el6

How reproducible:
Always

Steps to Reproduce:
1. Get the SPICE console of a VM.
2. Deselect the "Automatically resize" checkbox in the menu.
3. Go fullscreen (MAJ+F11).

Actual results:
The display is distorted due to scaling.

Expected results:
No scaling, nice display with, if necessary, black borders.

Comment 2 Marc-Andre Lureau 2014-01-17 13:59:18 UTC
(In reply to François Cami from comment #0)
> Description of problem:
> When the virt-viewer "Automatically resize" checkbox is OFF and "Fullscreen"
> mode is selected, the display is resized anyway.
> That means that on a native 2048x2048 physical screen displaying a 2000x2000
> SPICE client, going to fullscreen results in tearing due to non-native
> resolution.

You mean: when going fullscreen, the desktop resolution isn't changed, but the display is scaled, which results in drawing artifacts?

> Expected results:
> No scaling, nice display with, if necessary, black borders.

Checking virt-viewer code, I realize we always scale if necessary, while keeping aspect-ratio, in the general case, it make sense, for rebooting a VM, going to terminal console etc.. but also for zooming functionality.

Having a menu item would clutter a bit the UI, and is a bit harder to implement to handle disabling zooming logic. Having a more complex behaviour in fullscreen seems also difficult.

Would it be enough to provide a --no-scaling argument to virt-viewer? We would disable all scaling and zooming code in this case.

Comment 3 Marc-Andre Lureau 2014-01-17 14:08:35 UTC
(rather --disable-scaling)

Comment 4 François Cami 2014-01-17 15:42:44 UTC
Q: when going fullscreen, the desktop resolution isn't changed, but the display is scaled, which results in drawing artifacts?

=> yes.

Q: Would it be enough to provide a --no-scaling argument to virt-viewer?

=> The end goal is to be able to launch an console that never scales itself from the RHEV-M portals through spice-xpi, and I'm not sure we can pass arguments to that easily. However, for testing purposes I believe this would be OK!

Thank you.

Comment 5 Marc-Andre Lureau 2014-01-17 15:47:38 UTC
(In reply to François Cami from comment #4)
> => The end goal is to be able to launch an console that never scales itself
> from the RHEV-M portals through spice-xpi, and I'm not sure we can pass
> arguments to that easily. However, for testing purposes I believe this would
> be OK!

The spice-xpi or activex are more problematic, since the settings are received at run time. While arguments and .vv file is startup time only.

You can change activex or spice-xpi activated client and arguments via registry key and /usr/libexec/spice-xpi-client alternative script respectively.

Comment 6 Marc-Andre Lureau 2014-02-27 15:38:03 UTC
Sent a patch series adding a "Scale display" menu option to list:
https://www.redhat.com/archives/virt-tools-list/2014-February/msg00224.html

Comment 7 Marc-Andre Lureau 2014-06-03 14:03:21 UTC
back to NEW, the proposed solution is incomplete

Comment 8 Marc-Andre Lureau 2014-06-03 14:12:19 UTC
in the next virt-viewer release, the option "Automatically resize" has been removed, and enabled by default.

Since the guest should resize to 2048x2048, I am not sure it's worth adding a --no-scaling option anymore.

There are some issues with removing scaling in some cases, when display is larger than client window (smaller is easy, black border are ok). Either the client window would need to have a minimum size for the display (which can be pretty large), or the display would need to be embedded in a scrolled window, which is not a friendly solution either.

Francois, is it a requirement for the client window to have a different resolution than the guest, or was it merely a driver/agent limitation? (2048 vs 2000). thanks

Comment 9 François Cami 2014-06-03 14:32:18 UTC
Marc-André :
* the hardware is capable of 2048x2048 only.
* the guest should either be 2048x2048 or 2000x2000 unscaled (no tearing due to scaling) i.e. losing 48x48 pixels is fine but image quality issues are not.
* the driver/qxl is currently limited to 2000x2000 on a RHEL6 host, so the guest cannot scale to 2048x2048 and therefore the only solution is 2000x2000 *unscaled*.

Comment 10 Marc-Andre Lureau 2014-06-03 15:06:25 UTC
(In reply to François Cami from comment #9)
> * the driver/qxl is currently limited to 2000x2000 on a RHEL6 host, so the
> guest cannot scale to 2048x2048 and therefore the only solution is 2000x2000
> *unscaled*.

With xorg-x11-drv-qxl-0.1.1-12.el6.x86_64, I can reach 2048x2048. Is that enough?

Comment 13 Marc-Andre Lureau 2014-06-05 19:28:05 UTC
Created attachment 902639 [details]
0001-cairo-disable-scaling-if-SPICE_NOSCALE.patch

Comment 14 Marc-Andre Lureau 2014-06-05 19:29:36 UTC
should we go with that rhel-only spice-gtk patch? (I think it could find its place upstream as a hack/debug variable)

Comment 16 Marc-Andre Lureau 2014-06-12 14:03:43 UTC
ready, waiting for qa ack

Comment 22 errata-xmlrpc 2014-10-14 06:46:56 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-2014-1487.html


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