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

Bug #759803 reported by Alex Moldovan on 2011-04-13
This bug report is a duplicate of:  Bug #843432: unity-2d-panel crashed with SIGSEGV. Edit Remove
This bug affects 9 people
Affects Status Importance Assigned to Milestone
qt4-x11 (Ubuntu)
unity-2d (Ubuntu)
xserver-xorg-video-cirrus (Ubuntu)

Bug Description

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
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)
SourcePackage: unity-2d
UpgradeStatus: No upgrade log present (probably fresh install)

Alex Moldovan (alexmoldovan) wrote :
Alex Moldovan (alexmoldovan) wrote :
Changed in unity-2d:
importance: Undecided → High
Alex Moldovan (alexmoldovan) wrote :

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) wrote :

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

Florian Boucault (fboucault) wrote :

Bug is confirmed by duplicate bug #772122

Changed in unity-2d:
status: New → Confirmed
Changed in unity-2d (Ubuntu):
status: New → Confirmed
Martin Erik Werner (arand) wrote :

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

Using the cirrus video on I get the same as shown in above screenshot.

Using vga with, 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) wrote :

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.

summary: - Unity-2d not working on KVM
+ Unity-2d not working on KVM with xen and cirrus video devices
Jamie Strandboge (jdstrand) wrote :

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) wrote :

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) wrote :

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

Florian Boucault (fboucault) wrote :

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) wrote :

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.

Changed in unity-2d (Ubuntu):
importance: Undecided → High
Changed in unity-2d (Ubuntu):
assignee: nobody → Canonical Desktop Experience Team (canonical-dx-team)
Marc Pignat (swid) wrote :

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.

David Barth (dbarth) on 2011-07-20
Changed in unity-2d (Ubuntu):
assignee: Canonical Desktop Experience Team (canonical-dx-team) → Florian Boucault (fboucault)
Changed in unity-2d:
assignee: nobody → Florian Boucault (fboucault)
Changed in unity-2d (Ubuntu):
importance: High → Medium
status: Confirmed → Triaged
Didier Roche (didrocks) on 2011-07-20
Changed in unity-2d:
status: Confirmed → Triaged
Changed in qt4-x11 (Ubuntu):
status: New → Confirmed
Changed in xserver-xorg-video-cirrus (Ubuntu):
status: New → Confirmed
Marc Pignat (swid) wrote :

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) wrote :

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) wrote :

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) wrote :


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

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

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!


reini (rrumberger) wrote :

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

Changed in unity-2d:
assignee: Florian Boucault (fboucault) → nobody
Changed in unity-2d (Ubuntu Oneiric):
assignee: Florian Boucault (fboucault) → nobody
Alberto Mardegan (mardy) on 2011-09-07
tags: added: 24bit

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.

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
X.Org version 1.10.4

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.

tags: added: rls-mgr-o-tracking

This appears to have been fixed today.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers