[Mesa-dev] [RFC] New EGL extension: EGL_EXT_platform_display

Jakob Bornecrantz wallbraker at gmail.com
Tue Feb 26 06:23:08 PST 2013


[SNIP]

>> Hi,
>>
>> is it possible to build a binary, that will use this extension if it is
>> present in whatever libEGL is available at runtime, and if it is not,
>> fall back gracefully to using the core eglGetDisplay()?
>>
>> Or is this specifically not supported, since I cannot see a way for
>> runtime detection of this extension?
>>
>> Or is the runtime detection left unspecified, so one could do it with
>> e.g. getting eglGetPlatformDisplay via dlsym()?
>>
>> Just a question that popped in my mind, since there were no comments
>> toward that topic.
>
> Thanks for asking this question. I neglected to address the topic of runtime
> detection, despite it coming it up in face-to-face conversation multiple times.
>
> The function must be exposed with eglGetProcAddress, and must not be
> exported via dlsym.
>
> libEGL is not allowed to export new symbols until the EGL specification
> version is bumped. Exporting new symbols would prevent an applications
> compiled against one vendor's libEGL to load with another vendor's libEGL.

I assume that Mesa does not follow this rule?

>
> In architectures like Android, where the system provides the libEGL to which
> yhe application links and the vendor supplies an EGL driver that the system libEGL
> dlopens, exporting the symbol via dlsym would not expose the function
> to applications. The applications' only method for obtaining vendor-provided
> functions is via eglGetProcAddress.

I don't see this as driver extension and something that would need to be
implemented by the libEGL provider, since the selected platform might have
different set of drivers associated with them.

>
>> Or is this [runtime detection] specifically not supported, since I cannot
>> see a way for runtime detection of this extension?
>
> Since the function must be exposed by eglGetProcAddress, runtime detection
> will be supported. But... it's not obvious how to advertise the extension.

If memory serves me correct getProc can not return null for any string starting
with egl/gl/vg.

>
> I think the cleanest method by which applications could detect the extension
> is to first to connect to EGL_DEFAULT_DISPLAY; inspect the extension string;
> and, if the extension is available, then all with eglGetPlatformDisplay;
> otherwise, fallback to eglGetDisplay if possible.  The situation isn't ideal
> because it involves an initial roundtrip to the default platform's display
> server, but it's the best solution that I can think of.

That might include setting up a connection to a X server which is quite a
heavy handed thing to do. Less then optimal, also the extension might not
be supported by the loaded driver for the default platform but supported
by other drivers for other platforms.

Just throwing crazy ideas out there, maybe we should just call the function
xeglGetPlatformDisplay allowing implementation to return null if not
supported and as such being able to detection with eglGetProcAddress.

Cheers, Jakob.


More information about the mesa-dev mailing list