Requesting feedback on disallowing handle attribute values in EGLint attribute lists

Khronos is proposing a change affecting EGL attribute lists, and we’d appreciate feedback in this thread.

The EGL 1.4 specification defines EGLint as

EGLint is integral type used because EGL may need to represent scalar values larger than the native platform “int” type. All legal attribute names and values, whether their type is boolean, bitmask, enumerant (symbolic constant), integer, handle, or other, may be converted to and from EGLint without loss of information.

The purpose of this language was so that EGLint could be used to represent an arbitrary attribute value in EGL attribute lists.

However, the khrplatform.h headers Khronos distributed did not define this type correctly on 64-bit platforms with 32-bit native C “int” types, instead making EGLint a 32-bit type that is unable to represent handles and pointers. This header has since become imbedded in Linux EGL implementations and changing it would, essentially, break the EGL ABI on those platforms.

The EGL Working Group investigated currently defined EGL APIs and found the only cases where EGLint is actually expected to encode a handle today are as the EGL_MATCH_NATIVE_PIXMAP attribute value for eglChooseConfig, and the EGL_CL_EVENT_HANDLE_KHR attribute value for eglCreateSyncKHR in the EGL_KHR_cl_event extension.

After considerable discussion of options, we are proposing replacing the language defining EGLint in EGL 1.4 with the following:

Starting with the <date> release of EGL 1.4, EGLint is defined to be the same size as the native platform “int” type. Handle and pointer attribute values cannot be represented in attribute lists on platforms where sizeof(handle/pointer) > sizeof(int). Existing extensions which assume this functionality are being replaced with new extensions specifying new entry points to work around this issue.

We will also publish replacements for existing functionality which assumes it pass handles as EGLint attribute values. We think this path will minimize overall disruption. Going forward, we will define a new EGLattrib type for attribute lists requiring handle or pointer attribute values, or otherwise provide alternate APIs for specifying such attributes.

Jon Leech
EGL Spec Editor

We’ve had no feedback of any type on this issue, so we’re concluding it’s unlikely to affect anyone negatively. So we’ll be including this change in the next EGL 1.4 spec update, and will also have replacements for the handful of EGL extensions (KHR_cl_event, KHR_lock_surface2) which actually need to pass pointers in attribute lists.