Unity fails to load on old hardware on Saucy

[Colin Law]

On logging in I see just the wallpaper with no top panel and no launcher.
Note that this is not bug #1066764 (Unity fails to load on old hardware (compiz enabling LLVMpipe has no effect and Mesa tries to use hardware still)) as compiz is at 1:0.9.9~daily13.04.18.1~13.04-0ubuntu4 and the errors for that bug are not seen in .xsessionerrors.

.xsessionerrors only contains
Script for cjkv started at run_im.
Script for default started at run_im.

The graphics is an intel 865 chipset.

Xorg.0.log attached

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: unity 7.1.0+13.10.20130813.1-0ubuntu1
ProcVersionSignature: Ubuntu 3.11.0-2.5-generic 3.11.0-rc5
Uname: Linux 3.11.0-2-generic i686
ApportVersion: 2.12-0ubuntu3
Architecture: i386
CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins'
Date: Thu Aug 15 20:41:24 2013
InstallationDate: Installed on 2013-08-15 (0 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Alpha i386 (20130815)
MarkForUpload: True
SourcePackage: unity
UpgradeStatus: No upgrade log present (probably fresh install)

[Stephen M. Webb (bregma)]

I suspect this is because the Unity hardware detection (and subsequent fallback to software rendering) was removed from Compiz and added as a session startup script in Nux but the entire change has not made it through the distro landing process.

I'm going to suggest waiting a couple of days for the next Nux release into Saucy and test again.

[Colin Law (colin-law)]

I have the next release of nux-tools (4.0.2+13.10.20130816.2-0ubuntu1) but still see the issue. In fact now I am also seeing unity-support-test crash (bug #1213319). Since that bug has been marked a dup of bug #810182 which was marked fix released in January 2012 I am not sure what to do.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Stephen M. Webb (bregma)]

Yeah, it's very unfortunate that apport incorrectly marks bugs as dups and removes the traceback information before a developer gets a chance to look.

It really sounds like a problem when running unity-support-test during the boot sequence, and the fingers generally point to a bug in the OpenGL driver somewhere. Is there any way you could capture a stack trace (crash report, whatever) and attach to this bug instead?

[Colin Law (colin-law)]

Right, things have moved on. With the latest updates I am no longer getting the unity-support-test crash, so presumably something has been fixed there. I still don't get the launcher or panel in Unity, just the wallpaper as before. I still can't see anything interesting in any of the logs. However, I don't know whether it is significant, but when I open a terminal and run
compiz --replace
It restarts compiz and shows the wallpaper as before. I have attached the terminal output, the significant line may be
compiz (core) - Error: Plugin 'opengl' not loaded.

[Colin Law (colin-law)]

Right, things have moved on. With the latest updates I am no longer getting the unity-support-test crash, so presumably something has been fixed there. I still don't get the launcher or panel in Unity, just the wallpaper as before. I still can't see anything interesting in any of the logs. However, I don't know whether it is significant, but when I open a terminal and run
compiz --replace
It restarts compiz and shows the wallpaper as before. I have attached the terminal output, the significant line may be
compiz (core) - Error: Plugin 'opengl' not loaded.

[Stephen M. Webb (bregma)]

The log file you're looking for here is ~/.cache/upstart/gnome-session.log. Please check for that and attach it to this bug.

Running "compiz --replace" from the terminal will not necessarily start Unity. You are better off running /usr/bin/unity to restart unity so the correct configuration will pick up the correct plugins. Please try that instead to see if the output differs.

[Colin Law (colin-law)]

Running /usr/bin/unity gives very similar output, but not identical so
attaching unity.txt containing this.
Also attached gnome-session.log which does have errors.

I am also seeing a very strange problem on the machine where I cannot
login unless I have connected via an ssh shell before trying to login.
 Otherwise login just returns to the login prompt. Very odd and
probably not associated with this problem, but I thought I should
mention it in case it is relevant.

[Stephen M. Webb (bregma)]

Looking at the gnome-session.log file it appears there were problems with OpenGL support in X at some point. That seems to have disabled the OpenGL compiz plugin.

I'd suggest running the Compiz Configuration Settings Manager (ccsm) and unselecting the Unity plugin (if it's checked) and the re-selecting it. That should (hopefully) reset the basic configuration required to run Unity.

(As for the ssh-related problem, I've run into that with recent builds where remote X clients (wrongly) create a ~/.Xauthority file that the local session cannot overwrite: try removing all ~/.Xauthority files).

[Colin Law (colin-law)]

This is a clean install as of this morning, specifically to investigate this problem, so whatever the problem is it has been there since install time.

I installed ccsm and found that the Unity plugin is disabled. I enabled it and it said it needed OpenGL plugin, the Scale plugin and the Expo plugin which I enabled. It then told me there were some conflicts, which I said to ignore. It then showed the plugin as enabled. When I clicked Back to take me back to the top level of ccsm and then back into the Unity plugin again it once again showed as disabled. I tried saying Resolve Conflicts instead but it did not make any difference.

I then, in the top level tried enabling OpenGL explicitly. It showed checked but then after a few seconds deselected itself again.

So perhaps that is cause of the problem, it is not possible to enable the OpenGL plugin for some reason.
To check whether ccsm is able to save any settings I tried disabling png image loading, then closed ccsm and reopened it and it stayed disabled, and I was able to re-enable it ok.

(thanks for the .Xauthority file suggestions, that makes sense).

[Christopher Townsend (townsend)]

Hi Colin,

The Compiz opengl plugin is not loading, which is obvious:) So I've been thinking about why it's not loading on your machine. The "old hardware" in the bug title got me wondering what type of graphics hardware is in the system. I just now noticed that you wrote that you have Intel 865 graphics. After looking at http://en.wikipedia.org/wiki/Comparison_of_Intel_graphics_processing_units, this is Intel 2nd generation graphics and supports OpenGL 1.3.

Compiz/Unity require OpenGL 1.4 and above in order to work. The crapping out of the opengl plugin is not very friendly, but this is what is happening. I think you said that you tried forcing llvmpipe, but that didn't work, so I'm not really sure what you can do at this point.

For confirmation, try issuing /usr/lib/nux/unity_support_test -p and see what it says.

[Colin Law (colin-law)]

$ /usr/lib/nux/unity_support_test -p
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.3, 128 bits)
OpenGL version string: 2.1 Mesa 9.2.0

Not software rendered: no
Not blacklisted: yes
GLX fbconfig: yes
GLX texture from pixmap: yes
GL npot or rect textures: yes
GL vertex program: yes
GL fragment program: yes
GL vertex buffer object: yes
GL framebuffer object: yes
GL version is 1.4+: yes

Unity 3D supported: no

That looks a bit odd, it says that GL version 1.4 is supported.
I have tried forcing llvmpipe with LIBGL_ALWAYS_SOFTWARE=1 but that made no difference.

[Colin Law (colin-law)]

I have booted off a live Ubuntu 11.04 image and, with this old version of unity-support-test get

$ /usr/lib/nux/unity_support_test -p
OpenGL vendor string: Tungsten Graphics, Inc
OpenGL renderer string: Mesa DRI Intel(R) 865G x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 7.11

Not software rendered: yes
Not blacklisted: yes
GLX fbconfig: yes
GLX texture from pixmap: yes
GL npot or rect textures: yes
GL vertex program: yes
GL fragment program: no
GL vertex buffer object: yes
GL framebuffer object: yes
GL version is 1.4+: no

Unity 3D supported: no

So is this a straightforward bug in the latest unity-support-test?

[Christopher Townsend (townsend)]

Ok, well, it is trying to use llvmpipe. A fairly recent change in Nux handles this now (http://bazaar.launchpad.net/~unity-team/nux/trunk/revision/810#debian/50_check_unity_support).

Looking at the gnome-session.log, the failure is occurring when the open plugin is asking if the X session supports OpenGL/GLX and it is returning false which causes the opengl plugin to fatally error out. From the opengl plugin:
    glXGetConfig (dpy, visinfo, GLX_USE_GL, &value);
    if (!value)
    {
        compLogMessage ("opengl", CompLogLevelFatal,
                        "Root visual is not a GL visual");
        XFree (visinfo);
        screen->handleCompizEvent ("opengl", "fatal_fallback", o);
        setFailed ();
        return;
    }

I suspect something in llvmpipe is misbehaving, but what it could be is beyond my knowledge.

[Colin Law (colin-law)]

So that I understand, is the difference in unity-support-test between 11.04 and Saucy due to the fact that llvmpipe is (correctly) being used, so now GL1.4 /is/ supported (via s/w rendering)?
Also is it that glXGetConfig should actually return true, again because llvmpipe is in use?

Do we need to say Also Affects whatever package llvmpipe is in and hope someone jumps in?

[Stephen M. Webb (bregma)]

The mesa OpenGL driver is claiming OpenGL 2.1 is supported. The Xorg driver is not creating the default X visual with OpenGL support. That means one of two things:

(1) It's possible to configure Xorg to provide a GL-enabled visual as the default root visual, somehow, or

(2) The Xorg driver for your hardware, or Mesa 9.2, have a bug. Most likely the latter.

If I were a gambling man, my money would be on a bug in Mesa 9.2.0.

[Rick Harris (rickfharris)]

I've been bitten by this also on a new install, exhibiting exactly the same blank desktop with no icons, side launcher or top panel.

My gfx hardware is an Intel 855GM (not an 865 but is of the same generation chipset).

The OpenGL failure (Root visual is not a GL visual) and the resulting compiz opengl plugin failure is due to the intel driver defaulting to the new 'sna' (Sandybridge) renderer.

This generation of intel gfx cards needs the old 'uxa' renderer and so needs to be manually set in xorg.conf.d entry like so:

# cat /etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
   Identifier "Intel Graphics"
   Driver "intel"
   Option "AccelMethod" "uxa"
EndSection

That should give you a very slow but working software rendered Unity desktop.
It's debatable, but this slow desktop performance is probably unacceptable for everyday use.

The card only supports up to OpenGL-1.3 and Unity3D needs OpenGL-1.4+ which is why it falls back to software render.