[Mesa-dev] [PATCH] egl: Introduce alternative native display types

[Chia-I Wu]

2010/5/18 Kristian Høgsberg <krh at bitplanet.net>:
> On Tue, May 18, 2010 at 12:41 PM, Chia-I Wu <olvaffe at gmail.com> wrote:
>> 2010/5/18 Jakob Bornecrantz <wallbraker at gmail.com>:
>>> 2010/5/17 Kristian Høgsberg <krh at bitplanet.net>:
>>>> The EGL native platform API is determined at compile time and resolves
>>>> to Win32, X11 or Symbian at this point.   This means that if we want to
>>>> support XCB or a native DRM implementation, they have to be their platforms
>>>> and result in different libEGL.so's with identical ABI but different
>>>> entrypoint semantics.  From a distro point of view, and really, any point
>>>> of view, this is a mess, since the different libraries can't easily co-exist
>>>> without fiddling with linker paths.  And if you get it wrong, an application
>>>> requiring the X11 platform libEGL.so will happily link against any other
>>>> libEGL.so and segfault when eglGetDisplay() doesn't do what it expects.
>>>>
>>>> We can get around this by overloading the X11 native entrypoints instead.
>>>> The X Display struct has as its first member a pointer to XExtData.  The
>>>> pointer will always have bits 0 and 1 set to 0, which we can use to
>>>> distinguish a struct that's not an X display.  This lets us pass in a
>>>> custom struct that can provide initialization data for other platforms
>>>> in the same libEGL.so.
>>>>
>>>> The convention we're establishing is that the first field of such a struct
>>>> must be a pointer, so as to overlap with the layout of the X display
>>>> struct.  We can then enummerate the different display types using odd
>>>> numbers cast to a pointer (ensuring bit 0 is set).  This patch introduces
>>>> two new types of displays: EGL_DISPLAY_TYPE_DRM_MESA which lets us
>>>> initialize EGL directly on a DRM file descriptor or device filename and
>>>> EGL_DISPLAY_TYPE_XCB_MESA which lets us initialize EGL on X using an
>>>> xcb_connection_t instead of a classic Xlib Display.
>>>
>>> This sounds good to me, there are just some minor nitpicks that would
>>> be nice to be resolved.
>>>
>>> 1. Could you write some docu about EGLDisplayTypeDRMMESA, like that
>>> the display should return the FD after init in the struct. Also what
>>> happens if (drm->device_name == null && drm->fd < 0) looking at the
>>> code it would fail to load is this what we want?
>> I think the EGL prefix should be dropped.  We are defining a new
>> platform here: a platform whose display can be an xlib display, xcb
>> connection or drm.  It should not have the "EGL" prefix.
>
> That is a good point - so we'll call it MesaDisplayTypeDRM and
> MESA_DISPLAY_TYPE_DRM and similar for XCB.
>
>> Actually, I think this platform should have its own header file.
>> eglplatform.h will include the header file and typedef the native
>> types defined there to EGL types.
> You mean that the native types for the other platforms are defined in
> their respective header files and so should these new types?  I can
> see that point of view, but from a more pragmatic point of view, I
> don't think it's worth the trouble. Also, the types are specific to
> the mesa implementation, they are not data types from another display
> system or platform, and the Khronos implementors guide suggests that
> the vendor/implementor can modify eglplatform.h.
I just figured that if an application uses xcb_connection_t for the
display, it might as well use xcb types for windows and pixmaps.
Things could get really complex.  Do you have in mind how/when
xcb_connection_t will be used?

-- 
olv at LunarG.com