This issues occurs using eglGetPlatformDisplay(EGL_PLATFORM_GBM_KHR, ..) on Mesa 18.3.6. 1st Round ------------ First a surfaceless EGL context using an EGL display with EGL_DEFAULT_DISPLAY was created, which resulted in a proper capabilities readout as well as produced matching GL ES profile properties. This is executed in EGLDrawableFactory's GL profile probing. 2nd Round ---------- Afterwards an EGL display has been used with an actual GBM device, created via gbm_create_device(..); Here intention is to use a GBM surface via gbm_surface_create for the EGLSurface. However, even the resulting EGLConfig elements retrieved to match the GBM visualID differed from the 1st Round (see above). Continued execution uses a GBM surface via gbm_surface_create for the EGLSurface. The issue disclosed that from here on, GBM used a dumb buffer w/o hardware acceleration. Subsequent ioctl DRM calls drmModeSetCrtc(..) and drmModePageFlip(..) failed with the system error message 'Permission denied'. Workaround =========== In the 1st Round using an actual GBM device created via gbm_create_device(..) instead of using EGL_DEFAULT_DISPLAY works around this issue. +++ I believe the desired behavior should be to allow EGL_DEFAULT_DISPLAY also within GBM operations, as it worked well in the 1st Round but failed in the 2nd Round using the GBM device. Type 'ANNOTATION' to document this issue being only referenced here, but caused by an external component -> Mesa.
commit d7469d4fcbc6d92a696b90b52a75a233d4a30e5c Standalone native test attempting to reproduce issue Interestingly, the issue is no more reproducible. Weird. However, it is advised to use a real GBM device handle for EGL display creation under EGL_PLATFORM_GBM_KHR.