Bug 912810 - VM display is garbled if in 16-bpp
Summary: VM display is garbled if in 16-bpp
Status: CLOSED CANTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager   
(Show other bugs)
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-19 18:06 UTC by Francois Gouget
Modified: 2014-01-29 16:43 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-01-29 16:43:22 UTC
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)
Garbled 16-bpp display with QXL+VNC (531.28 KB, image/png)
2013-02-19 18:06 UTC, Francois Gouget
no flags Details

Description Francois Gouget 2013-02-19 18:06:44 UTC
Created attachment 699572 [details]
Garbled 16-bpp display with QXL+VNC

Description of problem:

I installed the QXL driver in a Windows XP SP2 QEmu/KVM VM. If I change the color depth to 16 bits per pixel the display becomes garbled (see attached screenshot). This is the case even if I tell Windows to reboot before applying the changes, and even after extra reboots.

However this problem goes away if I change from '<graphics type='vnc'.../>' to '<graphics type='spice'.../>'.

It's hard to tell where the problem comes from. The fact that changing from VNC to Spice fixes the issue makes me think the problem lies in virt-manager (or nearby). But changing the driver (while keeping the qxl graphics card) also fixes the issue so it may also be the Windows QXL driver.


Version-Release number of selected component (if applicable):

   The VM is running in QEmu/KVM on a 64-bit Debian host.
   libvirt-bin                        0.9.12-6
   libvirt0                           0.9.12-6
   python-libvirt                     0.9.12-6
   virt-manager                       0.9.1-4
   virt-viewer                        0.5.3-1
   qemu                               1.1.2+dfsg-5
   qemu-keymaps                       1.1.2+dfsg-5
   qemu-kvm                           1.1.2+dfsg-5
   qemu-system                        1.1.2+dfsg-5
   qemu-user                          1.1.2+dfsg-5
   qemu-utils                         1.1.2+dfsg-5

How reproducible:

   Systematic.

Steps to Reproduce:
1. Configure a Windows XP VM using the QXL driver.
2. Set up the remote diplay to '<graphics type='vnc'.../>'.
3. Connect to the VM using virt-manager.
4. In the VM, change the screen depth to 'Medium (16 bit)'.
5. Apply the changes (with or without rebooting).

Actual results:
See screenshot. Note that the mouse pointer is off too.

Expected results:
Normal 16-bpp display, just like when using either Microsoft's standard VGA driver or Spice to connect to the VM display.

Additional info:
 * 32-bit Windows XP Professional SP2 straight from CD, no windows updates.

 * The driver was installed from spice-guest-tools-0.3.exe which seems to ship a QXL driver built from this commit: 5020ad9f4a54d632daca3ccbc5522e3d44909c33
   http://spice-space.org/download.html

 * The screenshot was taken with virt-manager.

Comment 1 Cole Robinson 2014-01-29 16:43:22 UTC
Sorry this bug didn't get a response earlier.

virt-manager likely is not strictly at fault here: this is either a driver, qemu, or spice stack issue. Unfortunately it's hard to track down further since those three bits are all heavily intertwined.

My recommendation would be to try and reproduce with the latest versions of verything: qxl driver, qemu, and spice. Make sure you can reproduce with at least two spice clients (virt-manager and virt-viewer will do it). Then file an upstream spice-gtk bug for further triaging.

Closing this bug as CANTFIX strictly because I'm quite certain virt-manager is not at fault here, since all its spice handling is through spice-gtk


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