[Mesa-dev] (no subject)
krh at bitplanet.net
Fri Jun 11 06:35:36 PDT 2010
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.
>> I updated the eglkms.c test case, and it now compiles and runs against
>> this patch series:
>> [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:
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,
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:
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
/* X11 (tentative) */
typedef Display *EGLNativeDisplayType;
typedef Pixmap EGLNativePixmapType;
typedef Window EGLNativeWindowType;
typedef void *EGLNativeDisplayType;
typedef khronos_uint32_t EGLNativePixmapType;
typedef khronos_uint32_t EGLNativeWindowType;
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.
More information about the mesa-dev