On 07/12/16 08:27 PM, Jean-Philippe André wrote:
> Hey Derek,
>
> On 8 December 2016 at 07:41, Derek Foreman <der...@osg.samsung.com> wrote:
>>
>> commit cef41ae70a1c11565e1016debf6ce24ca259498d
>> Author: Derek Foreman <der...@osg.samsung.com>
>> Date: Wed Dec 7 16:39:17 2016 -0600
>>
>> gl_drm: Query eglGetProcAddress with dlsym
>>
>> eglGetProcAddress should be queried with dlsym unconditionally. What
>> we
>> had could query it with other extended forms of eglGetProcAddress,
>> which
>> is probably not what anyone wants.
>>
>> Also, throwing away the weird extended forms because there's a good
>> chance
>> our other gl bits don't run on any stacks that don't support normal
>> eglGetProcAddress.
>>
>>
> As you know eglGetProcAddress may not return NULL even if the extension is
> not supported.
Yes, apparently there are some gl stacks where it returns non-NULL for
eglGetProcAddress("Lol what were we smoking");
> We should refactor the whole thing to check the extensions string (after
> using a valid client context) before even calling eglGetProcAddress. That
> would avoid extra flags like in your other patch "gl_drm: Only use dmabuf
> if the extension is present".
Well that still won't go away because we need eglCreateImage() for more
than one extension. We need extra flags because eglGetProcAddress()
doesn't query extensions, it queries functions.
I agree completely that this should be refactored in some way though,
because right now it's a serious mess.
> Best regards,
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
