Bug 1054757
| Summary: | SPICE console is always scaled in fullscreen mode even if "Automatically resize" is disabled. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | François Cami <fcami> | ||||
| Component: | spice-gtk | Assignee: | Marc-Andre Lureau <marcandre.lureau> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
| Severity: | high | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 6.6 | CC: | cfergeau, codong, dblechte, djasa, dyuan, fcami, guillaume.sabouraud, herrold, jjongsma, lcui, marcandre.lureau, mzhan, rbalakri, tjamrisk, tlavigne, tzheng, zsong | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| 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.
|
Story Points: | --- | ||||
| Clone Of: | |||||||
| : | 1067346 (view as bug list) | Environment: | |||||
| Last Closed: | 2014-10-14 06:46:56 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1009648, 1067346 | ||||||
| Attachments: |
|
||||||
|
Description
François Cami
2014-01-17 12:29:53 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. (rather --disable-scaling) 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. (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. Sent a patch series adding a "Scale display" menu option to list: https://www.redhat.com/archives/virt-tools-list/2014-February/msg00224.html back to NEW, the proposed solution is incomplete 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 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*. (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? Created attachment 902639 [details]
0001-cairo-disable-scaling-if-SPICE_NOSCALE.patch
should we go with that rhel-only spice-gtk patch? (I think it could find its place upstream as a hack/debug variable) ready, waiting for qa ack 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 |