Help compiling mesa/gallium from git!
spitzak at gmail.com
Tue Feb 18 11:12:01 PST 2014
On 02/08/2014 01:30 AM, Pekka Paalanen wrote:
> *sigh*... I wrote a long nice reply and then my laptop crashed. Ok,
> here's the summary anyway.
Well I am wishing here I could see the longer reply but I am stuck.
Weston did not compile with an error similar to this until I added
"--disable-egl" but that seems to be knocking out the egl demo clients
which I thought this was going to allow to work. Even with this it still
fails to run with the following error:
[11:08:45.292] Using config file '/home/spitzak/.config/weston.ini'
[11:08:45.292] Loading module
[11:08:45.401] initializing x11 backend
[11:08:45.402] Loading module
[11:08:45.425] Failed to load module:
/home/spitzak/install/lib/libGLESv2.so.2: undefined symbol: _glapi_Dispatch
> - your configure line looks fine, but
> - you need --enable-gallium-egl, because you want software rendered
> Wayland GL/GLES apps to work
This does appear to default to off, but I really have no idea what they
are talking about. The help says:
--enable-gallium-egl enable optional EGL state tracker (not
EGL support in Gallium with OpenGL and OpenGL ES)
Anyway I turned it on. I also tried lots of other variations but the
current configure of mesa is this:
./autogen.sh --prefix=$WLD --enable-gles2 --enable-gallium-egl \
--with-egl-platforms=wayland,x11,drm --enable-gbm \
> - you need to use weston's pixman renderer, not gl-renderer.
> Sw-rendered GL apps will work anyway with egl_gallium.so, but not
> with egl_dri2.so.
Obviously this is the problem but I cannot figure out any configure
switch for weston that controls this. The only thing that seems remotely
related is "--with-cairo=image", but that did not help at all.
I can see it compiling gl-renderer but no idea how to stop it.
My last weston config line, trying to get this to work:
./autogen.sh --prefix=$WLD --disable-setuid-install --disable-colord \
> - you probably run not the binaries you think you are, because of
> the problems and the warnings about source being more recent than
> executable. That needs to be fixed. Check /proc/<PID>/maps for
> what binaries are loaded for a process.
No, it was loading the ones from install. But I think old ones, now that
I have uninstalled things don't link.
This is really getting frustrating as nothing I try seems to work.
Maybe you can correct my guess as to how all this software talks to each
1. An EGL-using wayland client talks to mesa's libEGL.
2. Somehow mesa decides to use Gallium rather than DRI (how? I see no
config option to cause this and attempting to disable DRI fails)
3. Mesa then uses the "gallium driver" called "swrast" to draw into a
4. Client does eglSwapBuffers, and mesa/Gallium then uses the "egl
platform" called "wayland" to do wayland attach + commit ? This one
really has me stumped as to how it is possible to make the "platform"
different than the "driver". My best guess is that "platform" is some
kind of option for the "swrast" driver and is not used by other drivers?
5. Wayland/weston get this and decide to composite using EGL. It *also*
talks to mesa's libEGL, sending it commands to composite.
6. Mesa again uses the "gallium driver" called "swrast" to draw the
composite into yet another buffer.
7. Wayland/weston does eglSwapBuffers and mesa/Gallium this time
magically decides to use the "x11" "egl platform" which then updates the
x11 window with the composited output.
It would also help a lot with any kind of description of what happens if
hardware supported EGL is working for either the compositor, the
clients, or both.
More information about the wayland-devel