Help compiling mesa/gallium from git!

[Bill Spitzak]

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 
'/home/spitzak/install/lib/weston/x11-backend.so'
[11:08:45.401] initializing x11 backend
[11:08:45.402] Loading module 
'/home/spitzak/install/lib/weston/gl-renderer.so'
[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 
required for
                           EGL support in Gallium with OpenGL and OpenGL ES)
                           [default=disable]

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 \
       --enable-shared-glapi 
--with-gallium-drivers=r300,r600,swrast,nouveau \
       --with-dri-drivers= --disable-dri3

> - 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 \
       --disable-rpi-compositor --disable-egl

> - 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 
other:

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 
memory buffer.

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.