In D12034#315525, @Christian Rauch (christian.rauch) wrote:

That's not entirely correct. The OpenGL symbols are defined in libOpenGL and libGL, so a Wayland client can also link libGL to get the symbols. While this is sub-optimal for a pure Wayland client as it introduces X11 link dependencies, it's perfectly valid and the only way if you have no way to install or distribute libOpenGL. See also the updated pull request description.

This is not valid if the pure Wayland enviroment doesn't have any X11 libs. It will fail to load as libGL will not exist.

Even without the X11 backend, we would still link libGL and thus libGLX with this work-around. However, this does not require to have an X server running or installed. With EGL we require libGL only to resolve the OpenGL symbols.

It requires the GLX to be installed. At least on my system, if I completly disable Xorg backend support, libGL and libGLX will not be there, and I don't see why it would be.

So if someone wants to run or compile a pure Wayland blender install, they can't as building and running our Wayland backend requires X11 backend support to be present on the system both during compile and during runtime.

In my eyes we will have to fix this sooner or later, so why hack this in quickly? Especially when there are ready solutions out there that already works and has solved this issue.
Now you have created a solution that forces us to not make a backend standalone and instead we always depend on the "legacy" backend and related libs to be present.

In D12034#315559, @Sebastian Parborg (zeddb) wrote:

This is not valid if the pure Wayland enviroment doesn't have any X11 libs. It will fail to load as libGL will not exist.

We are linking libGL because libOpenGL is not installed by default on common desktop environments. If neither libOpenGL nor libGL are available, you cannot have OpenGL at all. One of those libraries has to be installed. I don't see another way unless Blender ships it's own dependencies like other packaged formats do.

It requires the GLX to be installed. At least on my system, if I completly disable Xorg backend support, libGL and libGLX will not be there, and I don't see why it would be.

Which pure Wayland system and desktop are you using?

So if someone wants to run or compile a pure Wayland blender install, they can't as building and running our Wayland backend requires X11 backend support to be present on the system both during compile and during runtime.

You can compile Blender without the X11 backend but still link libGL. You also don't need any X11 stuff running so you can run this with a pure Wayland compositor without XWayland. The only thing you need is the libGL.so and its dependencies (libGLX.so, libX11.so). Blender-Wayland will not call any glx or x11 functions.

In my eyes we will have to fix this sooner or later, so why hack this in quickly? Especially when there are ready solutions out there that already works and has solved this issue.

If you have a pull request ready that solves that issue then please let me know. I am happy to review and test that.

Now you have created a solution that forces us to not make a backend standalone and instead we always depend on the "legacy" backend and related libs to be present.

I am not aware that having a Wayland-only build is a high priority on Blender's feature list. Blender linked libGL since forever. I don't know why it is now a high priority to remove that without even having the EGL context creation integrated. In fact even with only the Wayland backend enabled, Blender linked libGL since Wayland was merged and it was not an issue.

If you really have to run Blender-Wayland in an embedded system without any X11 libraries, then you can just "undo" the last commit that links libGL instead of libOpenGL.

@Christian Rauch (christian.rauch) could you make a design task that clearly presents the current library linking situation, and the proposed situation? I think it's vital to have this information laid out clearly, without having to read through long threads of comments on various Wayland-related patches.

Some considerations that I think are important to present/discuss/propose there:

• If Wayland can be installed & used without any X11 component, to me it doesn't make much sense for Blender to still require X11 on pure-Wayland builds. But maybe I'm wrong, in which case it should be described in that design task why X11 libs are still required in a Wayland-only build.
• What would happen to the default configuration? I think it's fine to have:
  • Wayland support optional, so only enabled if the build-time dependencies are installed.
  • X11 support could be made equally optional (if not already).
  • IMO we should have a way to build Blender with both X11 and Wayland support, and at runtime detect which one is available. Ideally this build would not require X11 libraries at runtime when running on Wayland, and vice versa.
• For each configuration (nothing, X11-only, Wayland-only, X11+Wayland), which system libraries will be (indirectly) linked by the binary, and which will be dlopen()ed?

Since I'm missing a "bigger picture" design, I find it hard to prioritise things, or even clearly see the impact of changes. For me this makes it impossible to aid in patch reviews. I guess this also counts for others, or we wouldn't have needed to revert rB0b18a618b88b: GHOST/X11: enable EGL.

In D12034#315734, @Sybren A. Stüvel (sybren) wrote:

@Christian Rauch (christian.rauch) could you make a design task that clearly presents the current library linking situation, and the proposed situation? I think it's vital to have this information laid out clearly, without having to read through long threads of comments on various Wayland-related patches.

I think I never created a Blender "design task" before. Can you point me to an example of how this is done? I agree that the current situation and propose solution have to be explained properly to make the right decisions.

Blender has a lot of communication channels (this developer review system, the devtalk forum, the chats and I think there are some other forums too). It's always hard for me to get in contact with the proper people.

In D12034#315567, @Christian Rauch (christian.rauch) wrote:

If you really have to run Blender-Wayland in an embedded system without any X11 libraries, then you can just "undo" the last commit that links libGL instead of libOpenGL.

Right, you could add that check to the code, so it links to libOpenGL when building for Wayland only?

if (WITH_GHOST_WAYLAND AND NOT WITH_GHOST_X11)
  # Link to libOpenGL (GLVND) and libEGL for pure Wayland builds, since libGL may not
  # be available Wayland only systems.
  list(APPEND BLENDER_GL_LIBRARIES OpenGL::EGL)
else()
  # Link to libGL and libEGL for X11 or mixed X11/Wayland builds, since libOpenGL
  # is not installed by default on Linux distributions like Ubuntu and we want to
  # create portable builds.
  list(APPEND BLENDER_GL_LIBRARIES ${OPENGL_egl_LIBRARY} ${${OPENGL_gl_LIBRARY}})
else()

This is of course all assuming we can get away without dlopen() and keeping GLEW, which is not clear yet.

I added the libOpenGL linking for the Wayland-only build.

Can someone let me know what I have to do to get this EGL support rolling? @Sybren A. Stüvel (sybren) mentioned a "design task" but I don't really know what that is.

In D12034#316089, @Christian Rauch (christian.rauch) wrote:

Can someone let me know what I have to do to get this EGL support rolling? @Sybren A. Stüvel (sybren) mentioned a "design task" but I don't really know what that is.

A design task is a task on phabricator (developer.blender.org) with a detailed proposal of how new functionality that is to be added to Blender should work.
For an example see: https://developer.blender.org/T78606

For smaller changes this is not needed, but for bigger new features (like Wayland support), we are supposed to create tasks like this and discuss the ideas and execution in detail before any development starts.
Otherwise we might end up in situations like we are now when a lot of work has already been done, but there are concerns about show stopper issues that could have been avoided.

I created a design task at https://developer.blender.org/T90676. There seem to be no objections against the proposal, but also no explicit confirmation of the approach.

Do you think this is sufficient? Shall we now go on with the proposed change?

In D12034#319113, @Christian Rauch (christian.rauch) wrote:

I created a design task at https://developer.blender.org/T90676. There seem to be no objections against the proposal, but also no explicit confirmation of the approach.

Do you think this is sufficient? Shall we now go on with the proposed change?

I think you have created a sufficient proposal that can be discussed. Thanks for pouring in your time to create it!

Sadly I haven't had time to properly interact with you about the proposal and our Linux maintainer @Sybren A. Stüvel (sybren) is on vacation.
I would have hoped that I would have had some time during the past weeks to properly respond and talk things out, but as you noticed, this hasn't been the case.

Please note that this hasn't been because of the lack of will, it is simply just that most of the developers including me has been (and often is overwhelmed) with work in general.

However this means that people like you that pours a lot of time into patches has a tendency to get put on ice and has no clue of what the hell is going on.
Which is not a pleasant experience for any of us...

I'll take some time now to write down my initial thoughts in the design task.

Has there been a consensus reached, on how to proceed with the X11-EGL integration?

From here on, I only see two options:

1. continue according to the proposal in T90676 and linking libGL.so->libGLX.so for X11-EGL builds, but link libOpenGL.so for upcoming Wayland-only and headless-only builds
2. replace GLEW with an alternative loader that dynamically resolves the linking dependencies
3. link modern OpenGL libs (GLVND) and make sure that Blender users have libOpenGL.so.0 installed (e..g via package libopengl0 or by shipping libOpenGL.so with Blender), this would be trivial for packaged formats like flatpak, snap or AppImage

I am pressing for a decision now, so I can decide if this very patch (D12034) should be merged or abandoned. As a hobbyist contributor, I only have the time for the intermediate solution of linking libGLX (option 1) or linking via GLVND (option 3). If Blender devs want to pursue replacing GLEW with an alternative (option 2), someone else has to step up to do that work.

I've talked to Sybren and Brecht.

The consensus is that if you are not willing to code in dynamic loading for the affected libraries, then this will be put on ice until someone else does it. (Or an acceptable alternate solution is created)
We've had same thing happen with for example alembic support in the past where other developers has taken over after the original developer didn't have any more time to spend on it.

The reason for why we put this on ice is because we will not be able to ship our official builds with wayland support as there is a high risk of it simply not loading/opening on a lot of linux systems.

We understand of course that you might not have time to work on alternatives, but we can't accept solutions that we don't think is good enough.
(Even if a lot of work has already been put in)

I am reviewing parts of this to keep the GLEW and GLES setup that is required for EGL support but keeps EGL disabled by default.

@Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht) @Julian Eisel (Severin) @Sybren A. Stüvel (sybren) Can you check this again? Originally, there was an issue with OpenGL linking when EGL is used. This issue is not present with EGL disabled. I tested this on a Ubuntu 20.04 live USB.

In D12034#394822, @Brecht Van Lommel (brecht) wrote:

I think it's fine to improve the build system for Wayland/EGL even if we are going to need bigger changes with dynamic loading to enable this by default in Blender builds.

As far as I remember, the original issue is that libOpenGL.so, which is required for "modern" GLVND OpenGL, is not installed by default on older systems. This is not an issue on "containerised apps" via flatpak or snap, or on distributions that can integrate and define those dependencies. If someone wants to provide a "blender-wayland" flatpak, snap or Debian package, then its better to have these patches integrated upstream so that one only has to set WITH_GHOST_WAYLAND at build time.

The changes in this patch look ok to me, but I think additionally we could auto enable WITH_GL_EGL if WITH_GHOST_WAYLAND is ON, since that's required?

This is already the case. In platform_unix.cmake, if WITH_GHOST_WAYLAND then set(WITH_GL_EGL ON).

In D12034#394834, @Christian Rauch (christian.rauch) wrote:

This is already the case. In platform_unix.cmake, if WITH_GHOST_WAYLAND then set(WITH_GL_EGL ON).

Ah right, can you move that code to the top level CMakeLists.txt then? Otherwise it won't influence the logic for auto disabling WITH_SYSTEM_GLEW.

Can I go ahead and merge this or does this patch needs additional approvals?

Let's wait for @Sybren A. Stüvel (sybren) to approve this also as the Linux maintainer.

You should also update the code review title and description to clarify what the patch does now.

@Sybren A. Stüvel (sybren) Can you have a look at this?

I updated the comments and documentation in the CMake file.

I apparently forgot to submit my answer to some of the comments. @Sybren A. Stüvel (sybren) Can you recheck this?

I've talked to Sybren, Sergey, Dalai, and Campbell about this.
We rather have this done properly so that we can turn on Wayland support in our official builds.
Would you be willing to work on replacing GLEW with libepoxy instead?

We want to be able to ship our official builds with Wayland support and not split up our binaries.
As you noticed Campbell has been working on the dynamic loading of Wayland libraries.
Once that is in the only missing part is the dynamic loading of opengl backends.
After looking around it seems like libepoxy is the thing we should use for this.

In D12034#412258, @Sebastian Parborg (zeddb) wrote:

Would you be willing to work on replacing GLEW with libepoxy instead?

As much as I would love to see the Wayland implementation happening in the default configuration, I fear that replacing GLEW with libepoxy is too much effort for a single spare-time contributor like me. The website says that this is as easy as just replacing the headers and the init calls, but I have no experience with this, so I don't know if there might be issues down the line.

The reason for switching to manual builds of GLEW for EGL is that the system GLEW does only build for GLX and you cannot have both (GLEW+GLX and GLEW+EGL) linked at the same time. The reason that GLEW+EGL isn't activated by default is that it dynamically links libOpenGL.so, which is only installed by default on newer systems (e.g. Ubuntu 22.04 and onward). libOpenGL.so needs to be installed manually (e.g. sudo apt install libopengl0) on Ubuntu 20.04 and below. Blender with EGL will fail to load if this library is not found.

Will we be able to ship the official Blender builds without GLX when using libepoxy? How does libepoxy solve this problem linking "modern" OpenGL?

Will we be able to ship the official Blender builds without GLX when using libepoxy? How does libepoxy solve this problem linking "modern" OpenGL?

It will load these dynamically at runtime and choose the appropriate library depending on what it can load.
As GLEW doesn't do this it will fail if any of the GL libraries doesn't exist when GLEW is loaded.

libexpoxy:

ldd /usr/lib/libepoxy.so.0.0.0
	linux-gate.so.1 (0xf7f16000)
	libc.so.6 => /lib/libc.so.6 (0xf7bc4000)
	/lib/ld-linux.so.2 (0xf7f18000)

GLEW:

ldd /usr/lib64/libGLEW.so.2.2.0
	linux-vdso.so.1 (0x00007ffec93c6000)
	libGL.so.1 => /usr/lib64/libGL.so.1 (0x00007f27c96ef000)
	libc.so.6 => /lib64/libc.so.6 (0x00007f27c94f8000)
	libGLdispatch.so.0 => /usr/lib64/libGLdispatch.so.0 (0x00007f27c9440000)
	libGLX.so.0 => /usr/lib64/libGLX.so.0 (0x00007f27c940c000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f27c984c000)
	libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f27c92ca000)
	libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f27c92a0000)
	libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f27c9299000)
	libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f27c9291000)
	libbsd.so.0 => /usr/lib64/libbsd.so.0 (0x00007f27c927a000)
	libmd.so.0 => /usr/lib64/libmd.so.0 (0x00007f27c926d000)

I added a few items to T76428: GHOST/Wayland Support to keep track of what needs to be done regarding EGL/GLEW/libexpoy.

I changed my mind and replaced GLEW with libepoxy (D15291). This will allow to build a client without linking OpenGL dynamically:

$ lddtree ./blender_build/bin/blender 
blender => ./blender_build/bin/blender (interpreter => /lib64/ld-linux-x86-64.so.2)
    libwayland-client.so.0 => /lib/x86_64-linux-gnu/libwayland-client.so.0
        libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8
    libwayland-egl.so.1 => /lib/x86_64-linux-gnu/libwayland-egl.so.1
    libxkbcommon.so.0 => /lib/x86_64-linux-gnu/libxkbcommon.so.0
    libwayland-cursor.so.0 => /lib/x86_64-linux-gnu/libwayland-cursor.so.0
    libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3
        libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0
            liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5
            libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1
            liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1
            libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2
            libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20
                libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0
    libdecor-0.so.0 => /lib/x86_64-linux-gnu/libdecor-0.so.0
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
    libepoxy.so.0 => /lib/x86_64-linux-gnu/libepoxy.so.0
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
    ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1

Awesome!
Thanks for taking your time and doing it!

I'll see if I have time next week to test and review it.

Not worth waiting for comment improvement to be reviewed, will commit now.