Similar to bug #83983, but hook up the GL-renderer, and select it with renderer=software-gl. If possible from within the headless backend, force Mesa to run llvmpipe. It's probably not possible, so some additions to the test scripts are needed. Mesa's EGL null platform might be useful for this. Actual rendering could be done to an FBO if needed. If EGL null platform init fails, the implementation is not Mesa, or whatever that implies the resident GL stack is not capable of running this test, the test needs to be skipped, not failed. Add a test, that excercises the GL-renderer; just start Weston on headless with GL, map a window, wait for a frame callback, and exit.
EGL null platform is available in Mesa >= 8 and <11, but it looks broken in Mesa >= 10.4 at least on my systems. It fails on eglInitialize(). I suspect that it was caused by http://lists.freedesktop.org/archives/mesa-dev/2014-November/070204.html In Mesa >=11 there's a new EGL platform surfaceless that replaced null platform but it requires access to /dev/dri/renderD<number>. Is it also a viable solution for this task or not really?
Oh great, another victim of killing egl_gallium.so, if that's true. The very point of software-rendering is that it doesn't need any access to gfx hardware, so requiring a render-node is a no-go. But does EGL surfaceless with llvmpipe really require a render-node? That would be silly... I'd be ok limiting to Mesa >= 11 at first, if that gets us a working setup. Depending on how much additional code it would be to support EGL null, it may or may not be nice to have it working on older Mesa.
Right, I asked around on #dri-devel and looked at Mesa a bit. The null platform has indeed been replaced by surfaceless, which apparently doesn't support software renderers. So, it requires implementing sw support in platform_surfaceless.c in Mesa. platform_wayland.c recently just got sw support, so maybe there's something to peek on. Software rendering would be quite useful for CI testing, because the buildbot would not need a real DRM device and could easily be a virtual machine etc. However, I suppose if platform_surfaceless can gain sw support later, it would not be a wasted effort to use platform_surfaceless with a real driver on a render node now. Getting the gl-renderer into the test suite coverage would be quite a big improvement. So, it might make sense to finish bug #83985 first, reverting the bug dependency.
In Aug/Sep we had the following discussion: http://lists.freedesktop.org/archives/wayland-devel/2015-August/024124.html which seemingly died off at: http://lists.freedesktop.org/archives/wayland-devel/2015-September/024128.html Since no-one has objected, I think we should be looking at that new plan instead.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/wayland/weston/issues/49.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.