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

[Kristian Høgsberg]

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.

> 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