EGL/glplatform.h: define EGL_CAST

[gizero]

C++ / C typecast macros for special EGL handle values: used by libepoxy code
The definition comes from the updated version of this header in mesa.

[popcornmix]

I'm not currently convinced this is the right thing to do.
I can't find any documentation for EGL_CAST so I'm not use if it is meant to be used outside of the system header files. Can you point at any?

The firmware (/opt/vc/) gl driver is currently being phased out and in the future the arm side (vc4-kms-v3d/vc4-fkms-v3d) driver will be recommended.
That uses the standard gl/egl header files provided by debian. I don't see reference to EGL_CAST in those files so relying on the macro may cause future problems.

I feel libepoxy might be better handling this itself. e.g.

#ifndef EGL_CAST
#define EGL_CAST(type, value) ((type) (value))
#endif

[jku]

Canonical upstream should be the Khronos EGL registry:
https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h

EDIT: Maybe more importantly the "egl.xml" from the same khronos EGL registry that is meant for generating egl headers contains references to EGL_CAST(): this where libepoxy gets them from.
https://www.khronos.org/registry/EGL/api/egl.xml

[JamesH65]

@popcornmix Seems that the Khronos headers do have this EGL_CAST macro, unless I have misread. Should we merge this?

[JamesH65]

@popcornmix Inclined to merge this. Thoughts?

[6by9]

Same thought as #467. What is relying on it, and does that then imply that something unsupported is going to work?

[JamesH65]

Used in https://github.com/anholt/libepoxy, but having taken a quick look, I think this now can cope with EGL_CAST not being defined - it does it itself.
https://github.com/anholt/libepoxy/blob/6769ba25bc2c5db15ef1485133df8ae6999a78b3/src/gen_dispatch.py#L496

So inclined to close, even though this does seem to be part of the Khronos spec (see links in post above)

[popcornmix]

It's not in the eglplatform.h that is in libegl1-mesa-dev from debian stretch.
So any program that relies on it with the firmware driver from /opt/vc/include will have a problem when moving to the arm side "standard" egl driver, which is the direction we are heading in.

As such I don't think it is correct to include it here.