Unity-2d not working on KVM with xen and cirrus video devices

[Alex Moldovan]

Binary package hint: unity-2d

The display is corrupted when using unity-2d on a KVM. See attached screenshot.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: unity-2d 3.8.2-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-8.42-generic 2.6.38.2
Uname: Linux 2.6.38-8-generic i686
Architecture: i386
Date: Wed Apr 13 09:26:53 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110329.1)
ProcEnviron:
 LANGUAGE=en_US:en
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: unity-2d
UpgradeStatus: No upgrade log present (probably fresh install)

[Alex Moldovan (alexmoldovan)]

Some of the video cards emulations do work. Here's the Update:

               Unity-2D Unity-3D

ciruss fails fails
vga works works
vmvga works works
xen fails fails

[Florian Boucault (fboucault)]

Thanks for the report Alex. Can you try any other Qt application in these conditions and see if they work properly?

[Florian Boucault (fboucault)]

Bug is confirmed by duplicate bug #772122

[Martin Erik Werner (arand)]

This is a slight regression, I was able to run unity-2d without this particular issue in version:
3.6.1-0ubuntu1

Using the cirrus video on 3.8.4.1-0ubuntu1 I get the same as shown in above screenshot.

Using vga with 3.8.4.1-0ubuntu1, the gtk-engine seems to work alright however the panels are still not:
The left panel flashes in solid white or is invisible constantly if using the mouse within the VM, it calms down and ends up in the distorted state seen on cirrus occasionaly, screenshot attached.

[Martin Erik Werner (arand)]

Ah, wrong of me, behavior described above was on "cirrus" as well, on "vga" both panels and gtk-eninge seems to work fine, similarly on "vmvga", on "xen" it simply won't boot for me.

[Jamie Strandboge (jdstrand)]

I can confirm that cirrus is busted and that vmvga works well with unity-2d. What I saw with the cirrus driver is similar to what I would see with konqueror in a vm, so this might be a qt bug.

[Jamie Strandboge (jdstrand)]

Subscribing the ubuntu-security team, since we use kvm extensively for testing VMs, and not having unity-2d as a fallback for unity 3d is a significant issue.

[Florian Boucault (fboucault)]

Garbage seen in the screenshot is reported as bug https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/791133

[Florian Boucault (fboucault)]

The crash in this bug report also happens with some other Qt programs: https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/791140

[Marc Pignat (swid)]

This bug is independent from 791133 (https://bugs.launchpad.net/ubuntu/+source/qt4-x11/+bug/791133).
Bug 791133 is a bug in mesa (opengl) and unity-2d uses the "raster" graphics system.

[Marc Pignat (swid)]

I have made some investigations, and I have almost found the bug.

* The X server has chosen a format with 24 bit depth and 24 bits_per_pixel, which seems
pretty unusual.

(source is qt/src/gui/image/qnativeimage.cpp)
* QNativeImage::format() returns either 16 or 32 bits, but never 24!
  -> This is the cause of the garbage in the display.

* QNativeImage::QNativeImage is called with the 32bit format, and allocates a Ximage (using XShmCreateImage) of the default (-> 24).
* Result : QImage thinks we've 4 bytes per pixel, XImage 3 bytes per pixel and this is the source of the segfault.

I have tried hacking QNativeImage::format() to return QImage::Format_RGB888, there is no more segfault, but the red and blue channels are inverted.

Hope this helps.

[Marc Pignat (swid)]

Here is more information:

I used these 2 applications from qt4-demos
* /usr/lib/qt4/examples/effects/fademessage/fademessage
* /usr/lib/qt4/examples/effects/blurpicker/blurpicker

kvm + cirrus (24-bit color / 24 bits per pixel)

graphicsystem | native | raster | opengl | opengl (mesa git/master)
---------------------------------------------------------------------------------
blurpicker | ok | garbage | garbage | ok
fademessage | red/blue inverted | garbage | garbage | ok

All of these tests are working fine using kvm + vga (24-bit color / 32 bits per pixel)

So it seems qt has some problems using 24 bits per pixel, and not only when using
the raster graphics system.

Is there some interest in getting this graphics system fixed for this unusual packet pixel
format, or should we go away and use the vga emulation?

[Marc Pignat (swid)]

Another version of my tests, since it is unreadable in launchpad:

blurpicker + native -> ok
blurpicker + raster -> garbage
blurpicker + opengl -> garbage
blurpicker + opengl (mesa git/master) -> ok

fademessage + native -> red/blue inverted
fademessage + raster -> garbage
fademessage + opengl -> garbage
fademessage + opengl (mesa git/master) -> ok

[reini (rrumberger)]

I'm using Kubuntu 11.04 and am getting some really similar glitches with normal (effects-enabled) KDE (not 100% reproducably, though). 24bpp is a really common value for all the machines I used in the last 8 years (X has been auto-detecting this for years). This is physical machines I'm talking about, btw.
IIRC, it used to be a pretty standard reply that 24bpp and 32bpp were essentially the same thing and, for some reason I never quite understood, X11 prefers the former.

I believe it is quite safe to say that 24bpp need to be supported properly...

[Marc Pignat (swid)]

Reini,

I just want to be sure were talking about the same thing,
color depth and bits_per_pixels are not the same.

On kvm + cirrus, this command give :
pim@pim-virt-pc1:~$ xdpyinfo | grep "depth 24"
    depth 24, bits_per_pixel 24, scanline_pad 32
pim@pim-virt-pc1:~$

And on all machines I have access to, it gives
pim@pim-home:~$ xdpyinfo | grep "depth 24"
    depth 24, bits_per_pixel 32, scanline_pad 32
pim@pim-home:~$

So both are 24 bits depth, but the cirrus uses 3 bytes for storing 24 bits and most other machines stores 24 bits on 4 bytes...

Can you please run this command?
xdpyinfo | grep "depth 24"

Thanks in advance!

Marc

[reini (rrumberger)]

I see. That must have to do with the part I failed to understand.
My mistake.

[nutznboltz (nutznboltz-deactivatedaccount)]

I was able to set 16bit depth.

In /etc/lightdm/lightdm.conf I appended

xserver-command=X -depth 16

no quotes.

Things appear much better now. The status bar in the upper right now displays all the icons and gadgets, before it was just blank.

The workspace switcher displays correctly.

[nutznboltz (nutznboltz-deactivatedaccount)]

I should mention that my previous comment about 16bit depth was while testing the cirrus graphics card emulation.

The version of the X server incremented recently causing a minor change in xdpyinfo output. Attached is a current copy of xdpyinfo from KVM/Qemu guest running with cirrus graphics emulation in 24bit mode.

X.Org version 1.10.2.902
X.Org version 1.10.4

[nutznboltz (nutznboltz-deactivatedaccount)]

When my KVM/Qemu VM guest is run with cirrus graphics emulation in 24-bit color depth mode none of the screenshots attached to this ticket look like what I'm seeing.

The attached screenshot shows the unity-2d-launcher icons are displayed correctly but it overlaps the menubar at the upper left because unity-2d-panel is not displacing it downward. The upper left of unity-2d-panel does not display the status icons, calendar, etc.

When I try to get the unity-2d-spread workspace switcher to open nothing happens to the screen while in the process table unity-2d-spread starts running. Then the segmentation fault mentioned in LP: #843448 occurs.

[nutznboltz (nutznboltz-deactivatedaccount)]

This appears to have been fixed today.