Recognizing wl_display pointer for EGL (Re: Smart comparing of wl_display_interfaces)

Kalrish Bäakjen kalrish.antrax at
Sat Oct 18 09:41:25 PDT 2014

If I understood it right, Dmitry, you are working on an EGL implementation
that should dynamically detect the type of the object passed to
eglGetDisplay. Mesa already does that, but it is ugly and just a hack that
should be avoided. eglGetDisplay was not designed to support multiple
platforms, hence why the EGL_EXT_platform_base[1] extension was conceived.
Consider implementing and switching to it - which, by the way, is part of
EGL 1.5.


On Fri, Oct 17, 2014 at 9:00 PM, Bill Spitzak <spitzak at> wrote:

> On 10/16/2014 11:16 PM, Pekka Paalanen wrote:
>  ...adding a function int/bool wl_is_wl_display_pointer(void *p) into
>> As that function would be built into
>>, it naturally uses the version of
>> wl_display_interface symbol (unless dynamic linking miraculously
>> manages to mess that up?).
>> 'p' would be the tentative 'struct wl_display *', so that the
>> implementation details of struct wl_display would be contained in
>>, and not leaked elsewhere like e.g. in Mesa.
> Might be better if the function was more like a cast. It returns either
> (wl_display*)p or NULL depending on the test. The reason is so the user can
> just assign it to a correct pointer without doing the cast themselves. This
> might be important if more of these casts are added in the future, it makes
> it harder to accidentally run the wrong test for the cast you want to do:
>   struct wl_display* wl_display_dynamic_cast (void* p) {
>     if (test(p)) return (struct wl_display*)p;
>     else return 0;
>   }
>  I am unsure about the exact definition of wl_is_wl_display_pointer():
>> can it do the dereferencability check itself, or should we require the
>> caller to guarantee that dereferencing cannot crash. The latter would
>> leave the portability burden on the callers rather than libwayland.
> Probably it should handle NULL.
> Maybe it should check alignment if wl_display has stricter alignment
> restrictions than some other plausable arguments.
> It does not seem to me that a check for pointing to valid memory is
> necessary.
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the wayland-devel mailing list