Getting egl clients to work
ppaalanen at gmail.com
Sun Jun 1 01:37:44 PDT 2014
On Tue, 27 May 2014 16:11:04 -0700
Bill Spitzak <spitzak at gmail.com> wrote:
> On 05/25/2014 11:22 PM, Pekka Paalanen wrote:
> > I suppose this refers to the DRI2 protocol for X11. I believe
> > it is an internal detail in getting Mesa EGL working properly
> > under X11 for Weston itself. This doesn't apply to totally
> > different graphics stacks like the Nvidia proprietary.
> > This has nothing to do with Wayland clients or Weston demo apps,
> > though. "The EGL" for Wayland clients is a different EGL
> > platform than what the compositor uses, and is mostly
> > orthogonal. For instance, even if the compositor does not have
> > EGL available, Wayland apps may still use EGL with a software
> > renderer (in Mesa's case this is currently implemented in
> > egl_gallium.so).
> > Xwayland is yet another story.
> > Maybe it would be best to not change the text here. If you
> > want, you can add a separate bullet point for the nvidia
> > proprietary driver telling when it got EGL support for both 32
> > and 64 bit machines, and that it could allow to run Weston only
> > with the x11-backend, and without support for hardware
> > accelerated clients/apps. You got this setup to work, right?
> > (If you have to use --use-pixman for Weston, then this is *not*
> > working and should not be mentioned.)
> > To me it still seems a pretty big loss of features compared to
> > a fully working stack.
> Okay I am not sure what is going on. You are right that I was
> guessing and may have guessed wrong.
> My current state:
> 1. I can only run the x11-compositor. It does appear to be using
> software egl, because if I remove $WLD/install/lib/dri I get
> these errors when trying to run weston:
> libEGL debug: failed to open
> /home/wspitzak/install/lib/dri/swrast_dri.so: cannot open shared
> object file: No such file or directory
> libEGL warning: DRI2: failed to open swrast (search paths
> libEGL debug: EGL user error 0x3001 (EGL_NOT_INITIALIZED) in
Sounds like you are using Mesa (software renderer) on your
system otherwise using Nvidia proprietary stack (right?).
At some point I thought you wanted to run Weston using Nvidia's
EGL to get hardware acceleration in Weston itself, not Mesa EGL
which on Nvidia proprietary drivers can only ever offer software
You should not install Mesa at all, if you wanted to use Nvidia's
libEGL, or otherwise make sure the correct libs get loaded.
Nvidia's libEGL can in theory work only with the x11-backend of
> 2. Under x11-compositor I can run most weston demo programs,
> include x programs. I can even run glxgears.
Software renderer for glxgears, I suppose. That's cool.
> 3. I cannot run weston clients that require egl, such as
> weston-simple-egl and weston-gears. weston-simple-egl prints all
> of this before failing (if I turn on the debugging information):
> $ weston/weston-simple-egl
> wl_callback at 9.done(25) libEGL debug: EGL user error 0x3001
> (EGL_NOT_INITIALIZED) in eglInitialize weston-simple-egl:
> clients/simple-egl.c:151: init_egl: Assertion `ret == 1' failed.
> Aborted (core dumped)
Yes, that is somewhat expected. Roughly put, because the libEGL used
by weston cannot offer hardware rendering, the libEGL used by apps
cannot offer hardware rendering either.
However, software rendering for apps can be made to work.
> The likely culprit seems to be "added egl_dri2 to module array"
> though I cannot figure out where this came from. The directory
> /home/wspitzak/install/lib/egl does not exist.
egl_dri2 is a built-in, not a file like egl_gallium.so. A
"side-effect" of egl_dri2 is that it does not implement the generic
software rendering path on the Wayland platform (i.e. for Wayland
Again, for Wayland apps to be able to use a software renderer from
Mesa, Mesa has to install egl_gallium.so and the apps need to use
it. When this is done properly, it does not matter to apps what EGL
Weston itself is using.
We come back to the issue, that you (running a proprietary graphics
stack) may want to use a different libEGL for Weston than what all
Wayland apps or Xwayland use, which is tricky to achieve. Maybe you
need to install Mesa to a completely different prefix, and write a
launcher script for Wayland EGL apps that will set up the
environment to point to the separate Mesa installation.
More information about the wayland-devel