[Mesa-dev] (no subject)

Chia-I Wu olvaffe at gmail.com
Fri Jun 11 13:17:54 PDT 2010


2010/6/11 Kristian Høgsberg <krh at bitplanet.net>:
> 2010/6/10 Chia-I Wu <olvaffe at gmail.com>:
>> Hi Kristian,
>>
>> 2010/6/4 Kristian Høgsberg <krh at bitplanet.net>:
>>> Here's an update on the EGL/DRM integration extensions and patches.
>>> I've updated the patches with the feedback from the discussions on the
>>> list to the extent that I think is feasible.  I think we're pretty
>>> close to consensus on how to do this, but let me know what you think.
>>> There's also a new extension in the series, the EGL_INTEL_no_surface
>>> extension, which lets us make a context current without a surface.
>> The summary looks fine to me.  Please go ahead with your changes.  I have one
>> comment below regarding the first patch.  It is fine to ignore it unless you
>> feel convinced.
>
> Cool, thanks.
>
>>> I updated the eglkms.c test case, and it now compiles and runs against
>>> this patch series:
>>>
>>>  http://cgit.freedesktop.org/~krh/mesa-demos/tree/src/egl/opengl/eglkms.c
>>>
>>> [PATCH 1/6] egl: Add MESA_typed_display infrastructure
>>>  This is the updated version of the alternative eglGetDisplay
>>>  extension.  I've incorporated the feedback from Chia-I regarding
>>>  naming of the entry point and tokens, and Jakobs suggestion that we
>>>  add tokens for the existing platforms (Win32 and X11).
>>>  It's still a new entrypoint, not separate .so's as Chia-I suggested.
>>>  I don't think it's a terrible idea to have separate .so's with
>>>  different names, but I still like this better, and with separate
>>>  .so's we'll have to compile libEGL several times to output the
>>>  different libraries, which is awkward and a pain for distributions.
>>>  I dropped the XCB display for now.
>> As the extension cannot be tested, it looks like a hack to me, only with a
>> spec.  Having separating libraries allows the issue to be resolved in the build
>> systems (of apps), instead of in the code.  Say, wayland is adopted by a mobile
>> device where there is DRM but no X server.  It is natural that eglGetDisplay on
>> that platform takes a DRM fd, and the extension becomes redundant.  If wayland
>> linked to libEGL-drm.so, whose eglGetDisplay expects a DRM fd, on a common
>> desktop, building wayland to the platform would require only a change to the
>> build rules.
>
> The typed_display isn't regular extension, you're right.  It's
> something between an extension and an implementation specific
> entrypoint (or as hack as you say :).  But I was actually sold on your
> libEGL-drm.so idea and went as far as implementing it:
>
>  http://cgit.freedesktop.org/~krh/mesa/log/?h=egl-kms-4
>
> This branch make the src/egl/main makefiles build two libraries:
> libEGL-x11.so and libEGL-drm.so, it generates egl-drm.pc and
> egl-x11.pc and symlinks libEGL.so to libEGL-x11.so and egl.pc to
> egl-x11.pc.  I was pretty happy with this until I tried using
> cairo-gl.  cairo-gl uses EGL to be able to save the users current
> context before it draws and then restore it when it's done.  It
> doesn't use any window specific entry points.  However, with the
> libEGL-drm.so approach, we would have to make cairo-gl choose to link
> to either libEGL-drm.so or libEGL-x11.so. And then you would either
> have to have a libcairo-drm.so and a libcairo-x11.so, or install cairo
> in different prefixes.  And while we may some day have a system with
> only wayland and no X, wayland and X will have to coexist forever on
> other systems (running rootless X applications on a wayland server,
> for example)
>
> Now, the typed display has a few problems of its own.  For
> applications that don't use X, eglplatform.h still pulls in X headers.
>  I worked around this in this commit:
>
>  http://cgit.freedesktop.org/~krh/mesa/commit/?h=egl-kms-3&id=55a59223be7cbb935ebbeee08fe25117210181a4
>
> but that's not good either, since we could have apps depending on
> eglplatform.h pulling the X headers.  And it relies on Display being a
> typedef of struct _XDisplay.  We could make this conditional on a
> #define, such as
>
>  #ifndef _MESA_EGL_NO_X11_HEADERS
>  /* X11 (tentative)  */
>  #include <X11/Xlib.h>
>  #include <X11/Xutil.h>
>
>  typedef Display *EGLNativeDisplayType;
>  typedef Pixmap   EGLNativePixmapType;
>  typedef Window   EGLNativeWindowType;
>  #else
>  struct _XDisplay;
>  typedef void *EGLNativeDisplayType;
>  typedef khronos_uint32_t  EGLNativePixmapType;
>  typedef khronos_uint32_t  EGLNativeWindowType;
>  #endif
>
> and it's probably better to just use a void * instead of the struct
> _XDisplay *, which is an implementation detail of Xlib (but a very
> public one, of course).  This has the benefit that one can add
> -D_MESA_EGL_NO_X11_HEADERS=1 to the compiler flags in the build system
> and avoid changing existing code.
>
> Finally, I'm thinking that instead of the generic typed_display
> mechanism, we could just go with a simple, typesafe:
>
>  EGLDisplay eglGetDRMDisplayMESA(int fd);
>
> and declare that in eglplatform.h. Using eglGetProcAddress() to look
> it up is a bit silly if your application only runs on drm.  In that
> case, getting a linker error up front if you're using the wrong
> libEGL.so is preferrable.  If you're writing an application that can
> run on both drm and X11, you can still use eglGetProcAddress() to try
> and see if the drm display is available.
>
> Anyway, I would like to go with the libEGM-drm.so idea, but it doesn't
> work well when you consider the larger software eco-system.  Aside
> from that, I'm OK with almost any one of these mechanisms, I tired of
> fighting the brokeness of EGL.  If only they'd done an egl-x11.h with
> eglGetX11Display(Display *dpy) and eglCreateX11WindowSurface(...,
> Window w, ...) we wouldn't have this problem.  I know, I sound like
> broken record, but this really is the most broken attempt at
> cross-platform I've ever seen. Sigh.
Thanks for looking into this.  I am fine with any of the solutions that
satisfies your need at this point.

I might perform some experiments next week though.  The idea, which is still
rough, is that EGL is an incomplete term.  It is only complete when the
platform is also spelled.  In other word, one may use EGL/X11 or EGL/WAYLAND,
but may never use EGL because there is no such thing.

EGL/X11 and EGL/WAYLAND are two different libraries with headers of their own.
The problem to solve, as what you've already done, is how to install both
libraries (and headers) parallelly.

This does not actually solve the issue with cairo-gl.  But built on this idea,
cairo, in its current form, does need to choose between EGL/X11 or whatever
EGL/<platform> there may be.  This is also the case with clutter.  clutter has
eglx and eglnative (but no egl!) backends.  Its solution is to install
libclutter-eglx-1.0 and libclutter-eglnative-1.0.

The good thing about cairo is that the way it uses EGL/<platform> may allow it
to pick one EGL/<platform> at runtime.  There might be no need for having
multiple libcairo-<platform>.  This is the direction I want to try.

-- 
olv at LunarG.com


More information about the mesa-dev mailing list