[Mesa-dev] Drooping multiple driver support in EGL?

[Kenneth Graunke]

On 12/22/2011 09:01 AM, Chia-I Wu wrote:
> Hi list,
> 
> Multiple driver support in EGL is hard to get right, if not impossible.
> On Linux desktop, we almost always want to use egl_dri2.  It allows EGL
> to loads DRI2 drivers, thus allowing it to share DRI2 drivers with
> libGL.
> 
> In one case where the app wants to use OpenVG, libEGL needs to load
> egl_gallium instead.  The problem comes from that we cannot know that an
> OpenVG context is to be created until it is created.  But before a
> context can be created, EGL needs to be initialized and an EGLConfig
> needs to be chosen.  So when EGL is to be initialized, we need to load
> and initilaize all EGL drivers.  When an EGLConfig is to be picked, we
> need to pick it from all drivers.
> 
> But this also introduces new problems.   For example, when the vendor
> string or the extension string is queried, whose string of all EGL
> drivers should be returned?
> 
> My proposal is to simply drop multiple driver support from EGL.
> Instead, we will provide four libEGL implementations:
> 
>  - libEGL_dri2: derived from egl_dri2
>  - libEGL_gallium: derived from egl_gallium
>  - libEGL_glx: derived from egl_glx
>  - libEGL_loader: see below

Somewhat tangentially...what is the advantage of egl_glx?  Does anybody
use it?   Why?  Is it being tested?

I'm mostly curious, as I've always used egl_dri2.

> All of them are conformant EGL implementations.  That is, any one of
> them can be installed as /usr/lib/libEGL.so.
> 
> libEGL_loader is new.  It is basically a wrapper that loads another
> implementation to do the real work.  As such, the problems we face with
> multiple driver support will remain in libEGL_loader.
> 
> Distros may choose to install libEGL_loader as libEGL and let it pick
> the real implementation.  Or they may choose to have the first three
> installed as libEGL, and package them separately.
> 
> Thoughts?