[waffle] [PATCH 13/18] api: make dl_can_open() dl_sym() display dependent

[Emil Velikov]

On 13/08/14 23:23, Chad Versace wrote:
> On 07/22/2014 08:31 PM, Emil Velikov wrote:
>> This will allow us to correctly work around waffle design which
>> allows the a library to be dl_open'ed if we support the corresponding
>> WAFFLE_CONTEXT (via waffle_display_supports_context_api).
>>
>> This is required by WGL which (as implemented in this patch) can
>> support ES contexts via EXT_create_context_es*_profile yet provides
>> all the symbols via a single library. We should check if ES context
>> can be create prior rather than blindly trying to retrieve the symbols.
>>
>> Once waffle has GL dispatch we can remove all the dl functions from
>> the waffle API, as we'll provide every function that the user needs.
>>
>> Note that this breaks the API in a non-backwards compatible way.
>>
>> TODO:
>>  - Add a note in the release notes.
>>
>> Signed-off-by: Emil Velikov <emil.l.velikov at gmail.com>
>> ---
> 
> The only remaining patch without review...
> 
> I don't agree with this patch and think it's unneeded. Perhaps I'm
> failing to see some subtelty of Windows.
> 
> Here's my argument. waffle_dl_can_open($LIB_FOR_API) doesn't guarantee
> that the platform supports $API. It can't. My Linux system, the one I'm
> typing on right now, supports the following feature matrix according to 
> wflinfo.
> 
> platform=gbm                           | GL  GLES1  GLES2  GLES3
> ---------------------------------------|-----------------------------
> waffle_dl_can_open                     |  T      T      T      T
> waffle_display_supports_context_api    |  T      T      T      T
> Can really create given context type   |  T      T      T      T
> 
> 
> platform=glx                           | GL  GLES1  GLES2  GLES3
> ---------------------------------------|-----------------------------
> waffle_dl_can_open                     |  T      T      T      T
> waffle_display_supports_context_api    |  T      F      T     *F
> Can really create given context type   |  T      F      T     *T
> 
> 
> On my system, GBM supports GLES1 but GLX doesn't. Therefore the ability to
> obtain functions with dlsym() should be independent of the display in use.
> This behavior intentionally differs from waffle_get_proc_address().
> 
> (To make it weirder, waffle_display_supports_context_api(glx_dpy, gles3) returns
> false despite that the GLX display is actually capable of creating a GLES3 context.
> This is because Mesa fails to advertise GLX_EXT_create_context_es_profile. This is
> a Mesa bug, and Waffle needs a workaround for it.)
> 
Ok let me put things in a different light:


   The Windows issue:

All the (GL1.0) symbols come from a single file on Windows - opengl32.dll,
while at the same time it's the display which knows if we should provide
symbols for the ES* APIs.


   The waffle confusion:

- waffle_dl_can_open
Handles dlopening a library based on the API requested.

- waffle_display_supports_context_api
States what context API can be used but not what API is purely/directly available.

I believe the issue here is dl_can_open is about a file to open, which may not
always map nicely to "I can get ES* context".


I don't mind dropping the patch although I would appreciate some hints on how
we can handle the "funny" Windows case.

Cheers,
Emil