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

[Chia-I Wu]

2010/5/28 Kristian Høgsberg <krh at bitplanet.net>:
> 2010/5/28 Chia-I Wu <olvaffe at gmail.com>:
> ...
>> 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.
>
> I think the "right fix" would be to define different, strongly typed
> display and surface constructors for different platforms.  For X11 you
> would have eglGetDisplayX11() that takes an X Display and
> eglCreateSurfaceFromXPixmap() etc.  For win32 you would have
> eglGetDisplayHDC() and we could add eglGetDisplayDRM() for the DRM fd
> case.  That way you get type safety and if you link to the wrong
> libEGL you don't get a crash or a runtime error, your application
> fails to link.  Quite an improvement.
>
> But it doesn't matter what we think the "right fix" may be, we need to
> work with what's there, including the already in-use "tentative" X11
> platform.
>
>> 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.
>
> I'm definitely in favor of 1) too.  The way I see it 2) isn't feasible
> as we break the existing and in-uise X11 API, 3) is just a different
> take on the (too) magic display I posted earlier and 4) doesn't solve
> the problem.
>> 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.
> Yeah, good suggestions.  I'm a little reluctant to splitting the
> extension; I can see why, but from a spec consumer point of view, the
> splitting of the EGLImage specs didn't help me figure out what was
> going on.  Keeping it in one spec gives a full picture of what's going
> on.  And there's an important difference in that you don't need to
> implement all the different display types to implement the extension.
> There's no way to check for the presence of the extensions or
> follow-on extensions anyway, all you can do is try to
> eglGetProcAddress to get the eglGetTypedScreenMESA() entry point.
Ah, right.  I forgot one cannot test the extensions without a display.
 Then I might favor 1) less.

How do you think about such scheme on a common desktop system

 - libEGL.so: the tentative x11 platform
 - libEGL-mesa.so: the MESA (bad name, but basically drm+xlib+xcb) platform
 - libEGL-directfb.so: the imaginary DirectFB platform
 - ... (more)

Multiple EGL libraries may be parallelly installed.  It is sort of
like the scheme of GTK+.  Applications then find the correct library
using the respective .pc file.  This is also more close to the "right
fix" you mentioned above.

libEGL-mesa is then free to define its own platform, or use
EGL_MESA_get_typed_display if you prefer.

Or if no mixed use of the drm/xlib/xcb is expected in  the near
future, split libEGL-mesa.so into libEGL-drm.so and libEGL-xcb.so.
Using eglGetDisplay(drm_fd) or eglGetDisplay(xcb_conn) is still more
direct IMHO.
>> 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.
> Well, it's a chicken and egg-problem with xcb.  Nobody will use it if
> it's not supported and you're suggesting we don't support it unless
> somebody uses it.  But I'm not too attached to it, I can drop it if it
> bugs you.
>
> Kristian
>

-- 
olv at LunarG.com