Skip to content

EGL: Allow adding EGLDeviceEXT handles

This is a fix for #215 (closed). It's a series of changes to allow vendor libraries to add new EGLDeviceEXT handles after the first call to eglQueryDevicesEXT.

Internally, libglvnd now maintains the (device -> vendor) hashtable by adding devices one handle at a time, just like it does for EGLDisplays.

Libglvnd now exposes a new function, __EGLapiExports::setVendorForDevice which allows a vendor-provided dispatch stub to add a new device to libglvnd's mapping. Any new extensions that return EGLDeviceEXT handles can use that to make sure that libglvnd knows what to do with a device. This also means that if the application doesn't call eglQueryDevicesEXT, but gets a device handle from some other function, then libglvnd will be able to look up that handle without needing to go through the full eglQueryDevicesEXT calls in each vendor.

When the application calls eglQueryDevicesEXT, libglvnd will now always forward the call to each vendor library, and it will update its mapping to include any new devices.

I also added a dispatch stub for eglQueryDisplayAttribEXT to libglvnd. Currently, that would be provided by vendor libraries, which of course don't currently call setVendorForDevice. The libglvnd stub ensures that eglQueryDisplayAttribEXT will work correctly without needing to update every vendor library.

Note that these changes only add support for adding new EGLDeviceEXT handles -- it doesn't support removing devices yet. Since a device could disappear in between two EGL calls, vendor libraries will probably need to be able to cope with getting calls with removed EGLDeviceEXT handles anyway.

Merge request reports