What was the reason for removing these attributes?
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
He Haocheng (2e40dee9) at 03 Jan 11:49
Dropped the GBM commit.
Looks good, Rb by me
There have been multiple reports of eglinfo crashing when GBM was queried (#39 (closed) and mesa#10123 (closed)). Those crashes are all because of buggy implementations and not the fault of eglinfo, but it seems bad that eglinfo crashes immediately upon encountering them.
In the case of eglinfo crashing while querying info about GBM, we still have other relevant info for bug reporting.
The other two commits do not cause functional changes, purely cosmetic.
From my understanding, the protocol effectively introduces a nested stacking window manager inside the original (tiling|stacking|scrolling|etc) manager.
It makes sense to me why it is needed for clients like Wine since (using Wine as an example) many Win32 applications, perhaps including the API itself, are designed with overlapping windows in mind, hence SetWindowPos. At the very least, the developers of those applications are far more likely to be familiar with stacking window managers than the tiling ones.
(Just my two cents)
(Original issue is at demos#41)
I would like to request for developer access to mesa/demos.
$ git shortlog -sne --author="Hoe Hao Cheng"
51 Hoe Hao Cheng <haochengho12907@gmail.com>
Thanks! I will create a new issue over there.
From my testing, it crashes on GBM platform only. eglinfo -p wayland
and eglinfo -p x11
works fine.
Looking at the output, the reason behind the segfault becomes obvious:
GBM platform:
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4
EGL client APIs:
eglinfo
never expected the client APIs field to be empty. This is seen only zink-on-GBM though since other drivers on GBM fail way earlier during EGL initialization.
With the above assumption fixed, we see another segfault on eglTerminate()
:
Program received signal SIGSEGV, Segmentation fault.
dri2_display_release (disp=0x5555555cc6f0) at ../src/egl/drivers/dri2/egl_dri2.c:1158
1158 assert(dri2_dpy->ref_count > 0);
(gdb) bt
#0 dri2_display_release (disp=0x5555555cc6f0) at ../src/egl/drivers/dri2/egl_dri2.c:1158
#1 0x00007ffff7d84bb1 in dri2_terminate (disp=0x5555555cc6f0) at ../src/egl/drivers/dri2/egl_dri2.c:1298
#2 0x00007ffff7d689e2 in eglTerminate (dpy=<optimized out>) at ../src/egl/main/eglapi.c:767
#3 0x000055555557c71d in doOneDisplay (d=0x5555555cc6f0, name=0x555555557979 "GBM", opts=...) at ../src/egl/opengl/eglinfo.c:634
#4 0x000055555557d297 in doExtPlatformBase (opts=...,
clientext=0x7ffff7d5a7f8 "EGL_EXT_client_extensions EGL_EXT_device_base"...) at ../src/egl/opengl/eglinfo.c:893
#5 0x000055555557d41e in main (argc=1, argv=0x7fffffffe048) at ../src/egl/opengl/eglinfo.c:930
As a side note, on latest mesa-git
, eglinfo-git
crashes on doExtExplicitDevice()
(cc @robertfoss):
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0 0x0000000000000000 in ?? ()
#1 0x000055555557d0b8 in doExtExplicitDevice (opts=...,
clientext=0x7ffff7d5a7f8 "EGL_EXT_client_extensions EGL_EXT_device_base"...) at ../src/egl/opengl/eglinfo.c:859
#2 0x000055555557d401 in main (argc=1, argv=0x7fffffffe048) at ../src/egl/opengl/eglinfo.c:927
Quick heads up: you probably have to force push your commits again because of the migration
Sorry for missing this on earlier reviews... but (uint32_t) texture_storage_metadata.modifiers
is enough for truncating the modifier down to 32 bits, the masking is redundant. (ps: it should be 1 << 32
)
Same for DMA_BUF_PLANE0_MODIFIER_HI, except that you need to shift it: (uint32_t) (texture_storage_metadata.modifiers >> 32)
There isn't a hard rule on thread resolving. That said, I would like to resolve them myself but apparently I don't have the permissions to do so? :/
Looks good to me. Thanks for working through this!
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
He Haocheng (db46c142) at 19 Oct 09:29
To make it clearer:
You can use GLAD to load GL functions, it's when we have two libraries doing the same thing (EGL/egl.h
+ glad/egl.h
, or GL/gl.h
+ glad/gl.h
) that things get a little messy. Because eglut
is already dependent on EGL/egl.h
that means glad/egl.h
is a no-go, but glad/gl.h
is still usable.
And since we already have the GetProcAddress function ready (eglGetProcAddress
), we can use gladLoadGL
(if we can continue using GL) or gladLoadGLES2
(if we have to use GLES) to load the GL functions directly. The gladLoaderLoad*()
functions are there to automate process of finding the relevant GetProcAddress function.
Also @kusma's suggestion make sense here, we should probably check for the validity of eglExportDMABUFImageQueryMESA
and eglExportDMABUFImageMESA
before using them.