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

[Kristian Høgsberg]

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.

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.

Kristian