(i945 only) Ubuntu Desktop Next fails to start; just black screen and mouse pointer (unity8.log: std::exception::what: Failed to create shared EGL context)

[Daniel van Vugt]

Ubuntu Desktop Next fails to start. I just get a black screen and mouse pointer. So unity-system-compositor is working fine. Only the nested unity8 can't run:

unity8.log:
~~~
()
[1420794321.348507] (II) SharedLibrary: Loading libmirplatform5driver.so
qtmir.mir: MirServer created
[1420794321.423199] (II) Server: Starting
libEGL warning: unsupported platform (null)
ERROR: /build/buildd/mir-0.10.0+15.04.20150107.2/src/server/graphics/nested/nested_display.cpp(85): Throw in function void mir::graphics::nested::detail::EGLDisplayHandle::initialize(MirPixelFormat)
Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt13runtime_errorEEEE
std::exception::what: Failed to create shared EGL context

ERROR: QMirServer - Mir failed to start
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::logic_error> >'
  what(): Cannot use configuration before apply_settings() call
~~~

I've also verified mir_proving_server with mir_demo_client_* runs fine in another VT.

[Daniel van Vugt (vanvugt)]

Hmm, actually this has only been reported on i945 systems so far (me and another person in:
https://bugs.launchpad.net/mir/+bug/1275398/comments/20

My Haswell desktop works fine with the same image. Maybe we're missing something in our relatively recent mesa patches to support i945?...

[Daniel van Vugt (vanvugt)]

Tested with mir-demos on the affected machine. Nesting works just fine with the mir-demos.

This bug then is just Unity8/QtMir choosing EGL config modifications that i945 systems can't support. Looking at the QtMir code, I would hazard a guess that the request for 8 bit stencilling is unreasonable:

class MirGLConfig : public mir::graphics::GLConfig
{
public:
    int depth_buffer_bits() const override { return 24; }
    int stencil_buffer_bits() const override { return 8; }
};

[Daniel van Vugt (vanvugt)]

Also, you shouldn't need a depth buffer for a desktop either. Throwing away that whole MirGLConfig, or at least loosening the restrictions should solve the problem.

[Daniel van Vugt (vanvugt)]

The problem could also be the incorrect selection of a MirPixelFormat.

[Daniel van Vugt (vanvugt)]

Reproduced on a third machine, where I could get a copy of the log file off.

[Daniel van Vugt (vanvugt)]

I'm not quite sure what QtMir is doing to trigger this. I've tried hacks to Mir directly to try and emulate what it might be doing, but my hacks result in nested servers starting and running perfectly still.

Something about QtMir I'm failing to emulate...

[Alexander Dobetsberger (masternoob)]

i can also reproduce this issue with the daily images on my eeepc (with i945 graphics)

[Alexandros Frantzis (afrantzis)]

Possible duplicate: bug 1418456 . It has some interesting backtraces and valgrind logs.

[Daniel van Vugt (vanvugt)]

Dropped from Critical to High. Because only affecting a small subset of older GPUs is not a release blocker for us.

[Andreas Pokorny (andreas-pokorny)]

The last time I tested those systems the main blocker I saw was our mesa package reporting a too low OpenGL version (the ES support would be fine enough for QtQuick btw). After some digging it seemed that the GL version is limited to 1.X, to avoid usage of certain full screen effects in unity7.

[Daniel van Vugt (vanvugt)]

Mir doesn't bother to interpret the OpenGL version string. It goes looking for the features it needs, properly. And the Mir demos almost all work properly on i945 (except for bug 1275684)

Although if QtMir was trying to interpret the version string, I'm not yet sure how that could cause this bug.

[Daniel van Vugt (vanvugt)]

Verified fixed on two i945 systems. Probably the Mesa 10.5 upgrade in vivid fixed this.

Unity8 on these older systems is a bit slow and I can't get through the welcome wizard fully. But it's not crashing any more so bug fixed!