Explicitly prefer legacy GL in cmake on Linux?

[kallaballa]

Pertaining Issue: #22835

Pull Request Readiness Checklist

See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request

• I agree to contribute to the project under Apache 2 License.
• To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
• The PR is proposed to the proper branch
• There is a reference to the original bug report and related work
• There is accuracy test, performance test and test data in opencv_extra repository, if applicable
  Patch to opencv_extra has the same branch name.
• The feature is well documented and sample code can be built with the project CMake

[kallaballa]

I am not so sure about that choice anymore. Because I made more research on #22704 and found the following statement "It allows EGL and GLX to coexist in the same process." here: https://www.x.org/wiki/Events/XDC2017/brenneman_GLVND.pdf

Also, at least on my system all the binaries that link EGL and GLX also link libGLdispatch as well. Including the opencv that is shipped with OpenSuse. Need to do more research and tests.

[kallaballa]

I did some experiments using GLVND. Including running a program using CL/GL (through EGL), CL/VA and highgui (imshow based on QT - with and without OpenGL). I'd also like to stress any code that uses the gl:: functions (which are loaded via GLX on Linux) but it seems like it isn't used in OpenCV and OpenCV_contrib. Where can I find code that relies on those functions? Can you think of good tests and other subsystems that might be affected?

Anyway I couldn't find any problems yet.

In legacy mode (with EGL patch enabled) the following libraries are linked to the OpenCV core so:

	linux-vdso.so.1 (0x00007ffe38bd5000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f8d2d23c000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f8d2bf73000)
	libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007f8d2d228000)
	libopenblas_pthreads.so.0 => /usr/lib64/libopenblas_pthreads.so.0 (0x00007f8d2a200000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f8d29e00000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007f8d2a11c000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f8d2a0fb000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f8d29c05000)
	libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f8d2a0c9000)
	libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f8d29b4e000)
	libgfortran.so.5 => /usr/lib64/libgfortran.so.5 (0x00007f8d29800000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f8d2d25c000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f8d296ba000)
	libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f8d2a082000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f8d2a057000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f8d2d21f000)

In GLVND mode (with EGL patch enabled) the following libraries are linked to the OpenCV core so:

	linux-vdso.so.1 (0x00007ffdc6a61000)
	libz.so.1 => /usr/lib64/libz.so.1 (0x00007f3c8be77000)
	libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f3c8be45000)
	libEGL.so.1 => /usr/lib64/libEGL.so.1 (0x00007f3c8be31000)
	libopenblas_pthreads.so.0 => /usr/lib64/libopenblas_pthreads.so.0 (0x00007f3c88e90000)
	libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f3c88c00000)
	libm.so.6 => /usr/lib64/libm.so.6 (0x00007f3c88b1c000)
	libgcc_s.so.1 => /usr/lib64/libgcc_s.so.1 (0x00007f3c88e6f000)
	libc.so.6 => /usr/lib64/libc.so.6 (0x00007f3c88921000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f3c887db000)
	libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f3c88724000)
	libgfortran.so.5 => /usr/lib64/libgfortran.so.5 (0x00007f3c88400000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f3c8be97000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f3c88e44000)
	libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007f3c886dd000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f3c8be28000)

So in both cases GLX, EGL and libGLdispatch are linked but in GLVND mode the old libGL isn't. So actually GLVND looks like the safer and better choice to me since it removes a dependency that has been deprecated since 2008.

[kallaballa]

Btw. because it has been abstracted well, replacing GLX based function pointer loading for Linux could easily be replaced with an EGL call.

opencv/modules/core/src/gl_core_3_1.cpp

Lines 131 to 133 in 6ca205a

	#include <GL/glx.h>
	#define CV_GL_GET_PROC_ADDRESS(name) glXGetProcAddressARB((const GLubyte*) name)

[kallaballa]

From this point i will document the progress on GLVND+EGL in PR #22704 because I have come to the conclusion that those decisions are linked and I want a single point of information.