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? _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev