[Mesa-dev] [PATCH] egl: Introduce eglGetDisplayMESA()

[Chia-I Wu]

2010/5/28 Kristian Høgsberg <krh at bitplanet.net>:
> 2010/5/27 Brian Paul <brianp at vmware.com>:
>> Kristian Høgsberg wrote:
>>>
>>> This patch introduces a new extension to allow different ways to
>>> create an EGLDisplay to exist within the same libEGL.so.  The new
>>> extension, EGL_MESA_get_display, introduces a new entrypoint:
>>>
>>>  EGLDisplay eglGetDisplayMESA(EGLint type, void *display)
>>>
>>> which takes an integer to identify the type of display to get and a
>>> void pointer to provide extra parameters for the display type in
>>> question.  At this point, three different display types are supported,
>>> EGLNativeDisplayType, DRM display and XCB display.
>>>
>>> Since an application needs to have an EGLDisplay before it can query
>>> for extensions, the way to discover this extension is to just use
>>> eglGetProcAddress().
>>> ---
>>>
>>> Ok, thinking about this some more, the whole deal with passing in a
>>> custom struct to eglGetDisplay() and relying on the layout of the X
>>> Display struct was just a little too magic.  And since any application
>>> using that needs to know about those structs and the display type
>>> defines anyway, we may just as well make a new entrypoint.  This feels
>>> a lot simpler and more robust, and we trade the eglplatform.h
>>> additions that Chia-I didn't like for a new extension in eglext.h.
>>
>> I haven't had time to follow the EGL work much lately.
>>
>> Could you write an extensions spec for this?  See docs/MESA_*.spec for
>> examples.
>
> Doing that now.
>
>> In the spec, could you explain in more detail what problem this extension
>> solves and maybe give an example of how it would be used?
>
> Chia-I, Jakob and I had a discussion in the thread about native egl
> displays a week ago about this and this patch is a rework or the patch
> that started that thread.  The motivation is that I want to use the
> same libEGL.so under X and on a KMS framebuffer without X.
>
> Instead of building support for one platform into libEGL.so at compile
> time, I'd like to build one libEGL.so that can support different ways
> of initializing. With the current approach you have to build different
> libEGL.so's for different platforms, which is fine as long as a
> platform is Linux/Win32/OSX.  But within the Linux platform, there are
> several "subplatforms": maybe you want to run under X with XCB instead
> of Xlib, or just bring EGL up on an DRM fd.  Dealing with different
> libEGL.so's for these variants is unpractical (and I'm sure
> distributions will hate that).  You have to change the LD_LIBRARY_PATH
> around or use -rpath to get the right libEGL.so. If you end up getting
> the wrong one, there's no way for libEGL to know what kind of
> EGLNativeDisplayType is passed to eglGetDisplay() so it'll just crash
> if there's mismatch.
> This extensions adds eglGetDisplayMESA() that lets you pass in an
> integer identifier to specify how you're initializing the EGL display.
>  This way, one libEGL.so can support a non-X mode of operation
> (running directly on a DRM fd as well as running on an X Display and
> an XCB display.  If you pass an unsupported display type, we can
> detect it cleanly and fail to initialize rather that just segfaulting.
Having multiple libEGL.so's is never a good idea, but I am not that
enthusiastic about the extension either.  Though I admit there is a dilemma
here.

The right fix is to define a sensible "xorg/drm" platform which has different
EGLNative{Display,Window,Pixmap}Type than the tentative ones as defined in
eglplatform.h.  The new platform should be able to fulfill all your
requirements.

The dilemma is that, the new platform is not compatible with the tentative x11
platform (as called in eglplatform.h), unless we play the magic trick in your
previous path series.

As such, it leaves 4 equally good options

 1) acknowledge the tentative x11 platform is official though ill-designed, and
    add EGL_MESA_get_display to support non-xlib toolkits
 2) replace the tentative x11 platform by a better but incompatible new
    platform
 3) extend the tentative x11 platform to support non-xlib toolkits "magically"
    (see attachment)
 4) Sorry, xcb and drm are only supported by manually setting EGL_DRIVER

I favor 1) slightly more than others, but I would like to hear more feedbacks.

As for the patch itself, I think eglGetDisplayMESA should be given another
name, such as eglGetTypedDisplayMESA.  Normally, eglFooBarEXT is expected to be
equivalent to eglFooBar.  And it might be a good idea to separate the extension
into

 * EGL_MESA_get_typed_display to define eglGetTypedDisplayMESA and
   EGL_NATIVE_DISPLAY_TYPE_MESA.
 * EGL_MESA_get_drm_display to define EGL_DRM_DISPLAY_TYPE_MESA.

The naming of the tokens is also slightly changed to fit the conventions of
other tokens.

If there is no immediate need for xcb support, I would prefer omitting it for
now.  If there is, then also a new extension for it.
> With this in place, the next step is another extension that lets us
> create an EGLImage from scratch (that is, not by lifting an existing
> client resource such as an GL renderbuffer) and get the DRM handle for
> the underlying buffer.  This will let us use the EGLImage as a
> renderbuffer with an FBO, and then use libdrm KMS API to setup the
> EGLImage as a scanout buffer.  It's a more  complicated process than
> the EGL_screen_surface extension, but it's lets use the libdrm KMS API
> directly to support page flips, multiple outputs, hotplug events, and
> puts control over double/multiple buffering in the applications hands
> (Want quad-buffering? Allocate four EGLImages).  And it can co-exist
> with the screen extension.
>
>> Should the dri2_get_driver_for_fd() function and related code be put into a
>> separate source file?  It seems it might be useful in other contexts.
>
> Yeah, at least the PCI ID list.  My long-term plan there is that I'd
> like to extract the PCI IDs from the DRI drivers automatically and
> store a map file with the DRI drivers (that is, in $libdir/dri).  I
> haven't looked at the DRI drivers to see if this is feasible, but I
> don't think they store the list of supported PCI IDs in any consistent
> way.  So it may be more trouble than it's worth and we could just
> maintain the map file by hand.

-- 
olv at LunarG.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesaxorg.h
Type: text/x-chdr
Size: 1570 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20100528/4d467c50/attachment-0001.h>