Bug 1402

Summary: Mesa 18.3.6 issues mixing EGL_DEFAULT_DISPLAY and GBM device on EGL_PLATFORM_GBM_KHR
Product: [JogAmp] Jogl Reporter: Sven Gothel <sgothel>
Component: embeddedAssignee: Sven Gothel <sgothel>
Status: RESOLVED INVALID    
Severity: normal    
Priority: P4    
Version: 2.4.0   
Hardware: embedded_all   
OS: linux   
Type: ANNOTATION SCM Refs:
d7469d4fcbc6d92a696b90b52a75a233d4a30e5c
Workaround: ---
Bug Depends on: 1156    
Bug Blocks:    

Description Sven Gothel 2019-11-27 23:01:42 CET
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.
Comment 1 Sven Gothel 2019-11-28 02:07:08 CET
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.