When using the gbm platform the extension MESA_query_driver is not exposed. Here is a sample code showing how to reproduce the issue: https://gist.github.com/jlHertel/0ec9b8ef1da0e314e0cef0cc18d4c83b Compile with g++ -o gbm_test.bin gbm_test.cpp -lgbm -lGL -lEGL -I/usr/include/libdrm -I/usr/include/EGL -ldrm Executing with EGL_PLATFORM=x11 ./gbm_test.bin works as expected and the extension EGL_MESA_query_driver is available. Executing with EGL_PLATFORM=gbm ./gbm_test.bin fails, saying that the extension is not available. Tested with MESA-git. Commit 87fa8d9ebc0dcd8c0ba1405d590ee6337fce69ba from Thu Jun 20 20:18:11 2019 -0700 My investigation so far makes me believe the issue is somewhat related to the way platform_drm.c is implemented. All other platforms make a call to dri2_create_screen(). This function is calling the drivers, and subsequently, loading the configuration options. On the comment of that function it says: " /* All platforms but DRM call this function to create the screen and populate * the driver_configs. DRM inherits that information from its display - GBM. */ " GBM doesn't seem to be loading the driver configuration, but unfortunately I have no clue where this is supposed to happen.
There is no gbm platform but it seems you found a bug : https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1834
(In reply to Lionel Landwerlin from comment #1) > There is no gbm platform Indeed, it's called "drm". We should probably print something when `EGL_PLATFORM` is set to something invalid.
I testes using EGL_PLATFORM=drm and it leads to the exact same issue. Any other idea?
(In reply to Jean Hertel from comment #3) > I testes using EGL_PLATFORM=drm and it leads to the exact same issue. > Any other idea? Not off the top of my head. I'll investigate tomorrow.
(In reply to Jean Hertel from comment #3) > I testes using EGL_PLATFORM=drm and it leads to the exact same issue. > Any other idea? Weird, it actually works for me now.
Curious, as for me it keeps failing to recognize the extension, both with my own compiled version and with Arch-provided version. Any other idea what could be wrong?
I made some additional debugging and found so far that when I run with EGL_PLATFORM=drm mesa loads by default /dev/dri/card0. When the driver tries to ioctl it to get additional data (on src/intel/dev/gen_device_info.c:1349), it receives a EACCES error, indicating that something is missing. If I hard-code on mesa to load /dev/dri/renderD128 I receive a ENOENT error. So I'm kinda lost of what could be wrong here. Maybe MESA opens the driver incorrectly? Or is this a i965 bug?
Sounds like your user isn't in the right group to access the devices, or the permissions got screwed up somehow. Can you give us the outputs of the following commands? $ ls -l /dev/dri/ $ lsattr /dev/dri/ $ groups
(In reply to Eric Engestrom from comment #8) > $ ls -l /dev/dri/ > $ lsattr /dev/dri/ > $ groups Ignore the `lsattr` one, I just tested and extended attributes aren't supported on dri devices
(In reply to Eric Engestrom from comment #8) > $ ls -l /dev/dri/ > $ lsattr /dev/dri/ > $ groups [jean@jean-notebook ~]$ ls -l /dev/dri/ total 0 drwxr-xr-x 2 root root 80 set 9 18:45 by-path crw-rw----+ 1 root video 226, 0 set 9 18:45 card0 crw-rw-rw- 1 root render 226, 128 set 9 18:45 renderD128 [jean@jean-notebook ~]$ groups sys network power docker lp wheel autologin jean
Try adding yourself to the video & render groups: usermod -aG video,render $USER I'm in both those groups on my system
(In reply to Eric Engestrom from comment #11) > Try adding yourself to the video & render groups: > usermod -aG video,render $USER > > I'm in both those groups on my system I tried adding myself but still face the same issue: [jean@jean-notebook ~]$ EGL_PLATFORM=drm LD_LIBRARY_PATH=/tmp/install/lib/ LIGL_DRIVERS_PATH=/tmp/install/lib/dri/ ./gbm_test.bin Err number: 13 Permission denied Extension EGL_MESA_query_driver missing! Available extensions: EGL_ANDROID_blob_cache EGL_EXT_buffer_age EGL_EXT_image_dma_buf_import EGL_KHR_cl_event2 EGL_KHR_config_attribs EGL_KHR_create_context EGL_KHR_create_context_no_error EGL_KHR_fence_sync EGL_KHR_get_all_proc_addresses EGL_KHR_gl_colorspace EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_3D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_no_config_context EGL_KHR_reusable_sync EGL_KHR_surfaceless_context EGL_EXT_pixel_format_float EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_image_dma_buf_export [jean@jean-notebook ~]$ groups sys network power docker video render lp wheel autologin jean [jean@jean-notebook ~]$ ls -l /dev/dri/ total 0 drwxr-xr-x 2 root root 80 set 9 20:42 by-path crw-rw----+ 1 root video 226, 0 set 9 20:42 card0 crw-rw-rw- 1 root render 226, 128 set 9 20:42 renderD128 Note: In the case above I'm running with my own-compiled mesa version, that has a small change to output the error code and the message when calling the ioctl. If I run with the mesa version I have installed on the system I still face the same issue.
I assume you logged out and back in, right? Try rebooting, on the off chance it makes a difference? Otherwise, can you `strace` your test to see exactly what goes wrong?
(In reply to Eric Engestrom from comment #13) > I assume you logged out and back in, right? Try rebooting, on the off chance > it makes a difference? > > Otherwise, can you `strace` your test to see exactly what goes wrong? I also tried to reboot just to be sure, but no success. I have done a strace of it with the following command: EGL_PLATFORM=drm strace ./gbm_test.bin > output.log 2>&1 The output.log can be seen here: https://pastebin.com/6h3ZLhBw
The problem is that on EGL+GBM, EGL itself does not load the driver (dri module), but gets it from GBM. In other words - dri2_load_driver* is missing in platform_drm, hence the dri2_bind_extensions(...optional_driver_extensions...) is not called and configOptions is NULL. IMHO we should fetch that in GBM and pass it along, just like we do for other driver extensions. I'm busy as hell, but feel free to CC me on patches/MR.
Aside, using eglGetDisplay() is a huge meh, considering how much of a hack it is and that we've had eglGetPlatformDisplayEXT for 5+ years.
(In reply to Emil Velikov from comment #16) > Aside, using eglGetDisplay() is a huge meh, considering how much of a hack > it is and that we've had eglGetPlatformDisplayEXT for 5+ years. I know eglGetDisplay() is bad, I used it to make the example simpler. I intend to use eglGetPlatformDisplayEXT to get the proper eglDisplay from the gbm devices. Also, thanks for pointing out what seems to be the issue. @Eric, if you post any patches, can you also CC me? I'm hugely interested in this. If this is not feasible, let me known, and I can try to fix the issue by myself.
I tested adding the suggested code and this fixed the issue. Merge request is here: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1923 Comments and welcome.
commit 2c1983f75767765686e8308a5841c5c26b5a0348 Author: Jean Hertel <jean.hertel@hotmail.com> Date: Tue Sep 10 21:00:07 2019 +0200 Fix missing dri2_load_driver on platform_drm Signed-off-by: Jean Hertel <jean.hertel@hotmail.com> Acked-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.