RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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...
Keywords:
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:
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)

Fixed In Version: spice-gtk-0.22-4.el6
Doc Type: Bug Fix
Doc Text:
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)
Environment:
Last Closed: 2014-10-14 06:46:56 UTC
Target Upstream Version:
Embargoed:

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
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1487 0 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.