Wayland support #90676

New Issue

Christian Rauch · 2021-08-14T22:13:44+02:00

Christian Rauch commented

2021-08-14 22:13:44 +02:00

1 Introduction

1.1 Motivation

Wayland is a communication protocol between a compositor and GUI clients that present content on a screen. It is adopted by major desktop environments on Linux and enabled by default on the majority of distributions (Fedora/RHEL, Debian, Ubuntu). In the long-term, it is expected that X11 clients will only be supported through XWayland. Blender should support Wayland to gain the benefits such as tear-free and "atomic" window updates, fractional scaling, access to newer input methods and generally to support a more efficient communication with the compositor.

1.2 OpenGL Context

1.2.1 Legacy

Legacy OpenGL on Linux would assume that OpenGL is always used together with X11. The GL library (libGL) would therefore define GLX and OpenGL symbols:

$ lddtree /usr/lib/x86_64-linux-gnu/libGL.so
libGL.so => /usr/lib/x86_64-linux-gnu/libGL.so (interpreter => none)
    libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
            ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0
        libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6
            libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1
                libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6
                libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
                    libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

libGL defines some OpenGL symbols (gl*) and all GLX symbols (glX*), as shown by nm --demangle --dynamic --defined-only --extern-only /usr/lib/x86_64-linux-gnu/libGL.so. libGLX defines a subset of GLX symbols.

1.2.2 Modern

Modern OpenGL separates OpenGL functions and context creation functions via GLVND into libOpenGL and libGLX or libEGL.

These libraries are not linked with each other. The EGL library:

$ lddtree /usr/lib/x86_64-linux-gnu/libEGL.so
libEGL.so => /usr/lib/x86_64-linux-gnu/libEGL.so (interpreter => none)
    libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
        ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

only defines EGL symbols (egl*) and is separated from the OpenGL library:

$ lddtree /usr/lib/x86_64-linux-gnu/libOpenGL.so
libOpenGL.so => /usr/lib/x86_64-linux-gnu/libOpenGL.so (interpreter => none)
    libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
            ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6

which only defines OpenGL symbols (gl*). libGLX only defines the GLX symbols (glX*) as above. You can check this with nm --demangle --dynamic --defined-only --extern-only.

There is no library that defines OpenGL and EGL symbols. Hence, to use "modern" OpenGL, an application has to link the OpenGL library and one of the context creation libraries.

Ubuntu and Fedora do not provide libOpenGL in the default installation. This library is provided via a package and has to be installed manually. Only libEGL and libGLX are provided in the default installation.

The only way to create an OpenGL context on Wayland is via EGL. EGL is also supported on X11. Wayland and X11 can therefore be enabled at the same time and use the same context creation procedures, removing the need to maintain GLX.

2 Current State

X11 (WITH_GHOST_X11) is enabled by default, while Wayland (WITH_GHOST_WAYLAND) is disabled by default at compile time.

X11 uses GLX to create the OpenGL context and uses either the system or external GLEW to query OpenGL function pointers. By default, WITH_SYSTEM_GLEW is OFF and hence the external GLEW is used. GLEW has to be compiled with either GLX or EGL support. It is not possible to use GLEW with a runtime selection of the context creation routines. Most distributions ship GLEW with GLX support enabled. Blender uses "legacy" OpenGL and links libGL to resolve GLX and OpenGL symbols.

If WITH_GHOST_WAYLAND is set ON, Blender has to use the external GLEW and compile this with EGL support. If WITH_GHOST_X11 is ON in parallel, this means that also the X11 backend switches to EGL. It will additionally link libEGL (but keep the "LEGACY" OpenGL preference).

The current behaviour can be summarised as:

`WITH_GHOST_X11`	`WITH_GHOST_WAYLAND`	effect on X server driven desktop	effect on Wayland server driven desktop	OpenGL context	linked libs	comment
ON	OFF	native X11 client	communicate as X11 client via XWayland	GLX	`libGL`, `libX11`	current default behaviour
OFF	ON	will not start	communicate directly via Wayland	EGL	`libEGL`, `libGL`, `libX11`	long-term goal of pure native Wayland client
ON	ON	will try Wayland first and fall back to native X11 client	communicate directly via Wayland	EGL	`libEGL`, `libGL`, `libX11`	interim solution with X11 fallback

3 Proposed Solution

3.1 GHOST

Since the Wayland option has to be set at compile-time, the Wayland backend has not received wide testing yet. Enabling Wayland at compile-time (WITH_GHOST_WAYLAND) and making it opt-in at runtime has been proposed in https:developer.blender.org/D11489. This would set WITH_GHOST_WAYLAND to on, but would still require to set the environment variable BLENDER_WAYLAND to probe the Wayland connection firstif X11 is enabled in parallel//. If Wayland is the only backend enabled at compile-time, it will be used regardless of the runtime BLENDER_WAYLAND.

`WITH_GHOST_X11`	`WITH_GHOST_WAYLAND`	`BLENDER_WAYLAND`	effect on X server driven desktop	effect on Wayland server driven desktop	comment
ON	OFF	--	native X11 client	communicate as X11 client via XWayland	same as above
OFF	ON	--	will not start	communicate directly via Wayland	same as above
ON	ON	unset	native X11 client	communicate as X11 client via XWayland	default behaviour
ON	ON	set	will try Wayland first and fall back to native X11 client	communicate directly via Wayland	interim solution with fallback

Note: WITH_GHOST_WAYLAND will always be set to OFF if one of its required build dependencies is not available.

3.2 OpenGL Context

To satisfy the following constraints:

Wayland needs EGL
GLEW cannot be built with GLX and EGL
distributions do not provide libOpenGL by default

To resolve the OpenGL symbols when EGL is used, I propose in https://developer.blender.org/D12034 to:

link libGL in the new default configuration (X11 and Wayland built in parallel)
link libOpenGL in a pure Wayland configuration (without X11)

Effectively, this means that Blender will by default continue to link libGL and additionally link libEGL for the EGL context creation. A pure Wayland built will use "modern" OpenGL and will not link any X11 symbol directly or indirectly. A distributed X11+Wayland binary will continue to work on default installations. A distributed Wayland-only binary will require to manually install the distribution packages that provide libOpenGL. The latter does not apply to "packaged" distributed binaries, such as deb, flatpak and snap packages, as those can define or provide their own dependencies.

4 Experimental Builds

blender-3.0.0-alpha+wayland-x11-fallback.ed1e4ab1bf3e-linux.x86_64-release.tar.xz : proposed default configuration with runtime switch to enable Wayland (e.g. BLENDER_WAYLAND= ./blender) and fallback to X11, links libGL
blender-3.0.0-alpha+wayland-no-x11.3e86bfbf936d-linux.x86_64-release.tar.xz : Wayland-only build without any X11 dependencies

# 1 Introduction ## 1.1 Motivation Wayland is a communication protocol between a compositor and GUI clients that present content on a screen. It is adopted by major desktop environments on Linux and enabled by default on the majority of distributions (Fedora/RHEL, Debian, Ubuntu). In the long-term, it is expected that X11 clients will only be supported through XWayland. Blender should support Wayland to gain the benefits such as tear-free and "atomic" window updates, fractional scaling, access to newer input methods and generally to support a more efficient communication with the compositor. ## 1.2 OpenGL Context ### 1.2.1 Legacy Legacy OpenGL on Linux would assume that OpenGL is always used together with X11. The GL library (`libGL`) would therefore define GLX and OpenGL symbols: ``` $ lddtree /usr/lib/x86_64-linux-gnu/libGL.so libGL.so => /usr/lib/x86_64-linux-gnu/libGL.so (interpreter => none) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ``` `libGL` defines some OpenGL symbols (`gl*`) and all GLX symbols (`glX*`), as shown by `nm --demangle --dynamic --defined-only --extern-only /usr/lib/x86_64-linux-gnu/libGL.so`. `libGLX` defines a subset of GLX symbols. ### 1.2.2 Modern Modern OpenGL separates OpenGL functions and context creation functions via [GLVND](https://gitlab.freedesktop.org/glvnd/libglvnd) into `libOpenGL` and `libGLX` or `libEGL`. These libraries are not linked with each other. The EGL library: ``` $ lddtree /usr/lib/x86_64-linux-gnu/libEGL.so libEGL.so => /usr/lib/x86_64-linux-gnu/libEGL.so (interpreter => none) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ``` only defines EGL symbols (`egl*`) and is separated from the OpenGL library: ``` $ lddtree /usr/lib/x86_64-linux-gnu/libOpenGL.so libOpenGL.so => /usr/lib/x86_64-linux-gnu/libOpenGL.so (interpreter => none) libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 ``` which only defines OpenGL symbols (`gl*`). `libGLX` only defines the GLX symbols (`glX*`) as above. You can check this with `nm --demangle --dynamic --defined-only --extern-only`. There is no library that defines OpenGL and EGL symbols. Hence, to use "modern" OpenGL, an application has to link the OpenGL library and one of the context creation libraries. Ubuntu and Fedora do not provide `libOpenGL` in the default installation. This library is provided via a package and has to be installed manually. Only `libEGL` and `libGLX` are provided in the default installation. The only way to create an OpenGL context on Wayland is via EGL. EGL is also supported on X11. Wayland and X11 can therefore be enabled at the same time and use the same context creation procedures, removing the need to maintain GLX. # 2 Current State X11 (`WITH_GHOST_X11`) is enabled by default, while Wayland (`WITH_GHOST_WAYLAND`) is disabled by default at compile time. X11 uses GLX to create the OpenGL context and uses either the system or external GLEW to query OpenGL function pointers. By default, `WITH_SYSTEM_GLEW` is OFF and hence the external GLEW is used. GLEW has to be compiled with either GLX or EGL support. It is not possible to use GLEW with a runtime selection of the context creation routines. Most distributions ship GLEW with GLX support enabled. Blender uses "legacy" OpenGL and links `libGL` to resolve GLX and OpenGL symbols. If `WITH_GHOST_WAYLAND` is set ON, Blender has to use the external GLEW and compile this with EGL support. If `WITH_GHOST_X11` is ON in parallel, this means that also the X11 backend switches to EGL. It will additionally link `libEGL` (but keep the "LEGACY" OpenGL preference). The current behaviour can be summarised as: | **`WITH_GHOST_X11`** | **`WITH_GHOST_WAYLAND`** | *effect on X server driven desktop* | *effect on Wayland server driven desktop* | *OpenGL context* | *linked libs* | *comment* | | -- | -- | -- | -- | -- | -- | -- | | ON | OFF| native X11 client | communicate as X11 client via XWayland | GLX | `libGL`, `libX11` |current default behaviour | | OFF | ON | will not start | communicate directly via Wayland | EGL | `libEGL`, `libGL`, `libX11` | long-term goal of pure native Wayland client | | ON | ON | will try Wayland first and fall back to native X11 client | communicate directly via Wayland | EGL | `libEGL`, `libGL`, `libX11` | interim solution with X11 fallback | # 3 Proposed Solution ## 3.1 GHOST Since the Wayland option has to be set at compile-time, the Wayland backend has not received wide testing yet. Enabling Wayland at compile-time (`WITH_GHOST_WAYLAND`) and making it opt-in at runtime has been proposed in https:*developer.blender.org/D11489. This would set `WITH_GHOST_WAYLAND` to on, but would still require to set the environment variable `BLENDER_WAYLAND` to probe the Wayland connection first*if X11 is enabled in parallel//. If Wayland is the only backend enabled at compile-time, it will be used regardless of the runtime `BLENDER_WAYLAND`. | **`WITH_GHOST_X11`** | **`WITH_GHOST_WAYLAND`** | `BLENDER_WAYLAND` | *effect on X server driven desktop* | *effect on Wayland server driven desktop* | *comment* | | -- | -- | -- | -- | -- | -- | | ON | OFF| -- | native X11 client | communicate as X11 client via XWayland | same as above | | OFF | ON | -- | will not start | communicate directly via Wayland | same as above | | ON | ON | unset | native X11 client | communicate as X11 client via XWayland | default behaviour | | ON | ON | set | will try Wayland first and fall back to native X11 client | communicate directly via Wayland | interim solution with fallback | Note: `WITH_GHOST_WAYLAND` will always be set to `OFF` if one of its required build dependencies is not available. ## 3.2 OpenGL Context To satisfy the following constraints: - Wayland needs EGL - GLEW cannot be built with GLX and EGL - distributions do not provide `libOpenGL` by default To resolve the OpenGL symbols when EGL is used, I propose in https://developer.blender.org/D12034 to: - link `libGL` in the new default configuration (X11 and Wayland built in parallel) - link `libOpenGL` in a pure Wayland configuration (without X11) Effectively, this means that Blender will by default continue to link `libGL` and additionally link `libEGL` for the EGL context creation. A pure Wayland built will use "modern" OpenGL and will not link any X11 symbol directly or indirectly. A distributed X11+Wayland binary will continue to work on default installations. A distributed Wayland-only binary will require to manually install the distribution packages that provide `libOpenGL`. The latter does not apply to "packaged" distributed binaries, such as deb, flatpak and snap packages, as those can define or provide their own dependencies. # 4 Experimental Builds - [blender-3.0.0-alpha+wayland-x11-fallback.ed1e4ab1bf3e-linux.x86_64-release.tar.xz ](https://builder.blender.org/download/experimental/blender-3.0.0-alpha+wayland-x11-fallback.ed1e4ab1bf3e-linux.x86_64-release.tar.xz): proposed default configuration with runtime switch to enable Wayland (e.g. `BLENDER_WAYLAND= ./blender`) and fallback to X11, links `libGL` - [blender-3.0.0-alpha+wayland-no-x11.3e86bfbf936d-linux.x86_64-release.tar.xz ](https://builder.blender.org/download/experimental/blender-3.0.0-alpha+wayland-no-x11.3e86bfbf936d-linux.x86_64-release.tar.xz): Wayland-only build without any X11 dependencies

Christian Rauch commented

2021-08-14 22:13:44 +02:00

Added subscribers: @christian.rauch, @ideasman42, @brecht, @JulianEisel, @dr.sybren, @ZedDB

Paul Larson commented

2021-08-14 23:26:46 +02:00

Added subscriber: @GeorgiaPacific

Sebastian Parborg commented

2021-08-24 13:06:39 +02:00

A few thoughts:

As stated before I think that we should start the wayland backend without any special flags that needs to be set.
We could of course provide a flag to to force the use of the x11 backend even when wayland is detected.

This is because I think and I am certain that you will not get enough test as you are already targeting the currently very small wayland user base on linux.
Of those using the wayland backend, I don't think they would think of using the wayland back end unless they are hardcore wayland users.
So of that very small subset of blender wayland users, you are targeting an even smaller subset of that user base.
In addition to this they also have to use the experimental builds which narrows this down even further.

If it is ready for testing then at least to me, it should be on by default.
Then you will know for sure if it is ready for prime time when the release window closes.

According to the nvidia driver documentation: https://download.nvidia.com/XFree86/Linux-x86_64/390.42/README/installedcomponents.html

Repackagers of the driver are encouraged to provide the GLVND-based driver stack to promote adoption of the new infrastructure, but those who choose to package the legacy GLX client library instead of, or as an alternative to, the GLVND GLX client library should be aware that the NVIDIA EGL driver depends upon GLVND for proper functionality. The legacy GLX client library may coexist with most GLVND libraries, with the exception of libGL.so.1 and libGLX.so.0, so it is possible to support both NVIDIA EGL and legacy, non-GLVND NVIDIA GLX by installing all of the GLVND libraries except for libGL and libGLX alongside the legacy libGL.

This implies that EGL might not work on nvidia cards without libOpenGL (GLVND).

Has this been tested?

I have a sneaking suspicion that this is why quite a few projects have switched from GLEW to libepoxy or other alternatives so they can switch between EGL and GLX at runtime.
(So they can fallback to GLX nvidia systems that doesn't have the GLVND library installed)

What is the plan for loading wayland libraries?
As far as I know we can't (or at least shouldn't) statically link the wayland libraries.
So this means that unless you dlopen these, our binaries will not run on systems that lack them.

The same is true for pure wayland systems of course as well. If there is not x11 libraries installed, our binary will fail to load.

How do you plan to tackle this issue?

A few thoughts: --- As stated before I think that we should start the wayland backend without any special flags that needs to be set. We could of course provide a flag to to force the use of the x11 backend even when wayland is detected. This is because I think and I am certain that you will not get enough test as you are already targeting the currently very small wayland user base on linux. Of those using the wayland backend, I don't think they would think of using the wayland back end unless they are hardcore wayland users. So of that very small subset of blender wayland users, you are targeting an even smaller subset of that user base. In addition to this they also have to use the experimental builds which narrows this down even further. If it is ready for testing then at least to me, it should be on by default. Then you will know for sure if it is ready for prime time when the release window closes. --- According to the nvidia driver documentation: https://download.nvidia.com/XFree86/Linux-x86_64/390.42/README/installedcomponents.html > Repackagers of the driver are encouraged to provide the GLVND-based driver stack to promote adoption of the new infrastructure, but those who choose to package the legacy GLX client library instead of, or as an alternative to, the GLVND GLX client library should be aware that the NVIDIA EGL driver depends upon GLVND for proper functionality. The legacy GLX client library may coexist with most GLVND libraries, with the exception of libGL.so.1 and libGLX.so.0, so it is possible to support both NVIDIA EGL and legacy, non-GLVND NVIDIA GLX by installing all of the GLVND libraries except for libGL and libGLX alongside the legacy libGL. This implies that EGL might not work on nvidia cards without `libOpenGL` (GLVND). Has this been tested? I have a sneaking suspicion that this is why quite a few projects have switched from GLEW to libepoxy or other alternatives so they can switch between EGL and GLX at runtime. (So they can fallback to GLX nvidia systems that doesn't have the GLVND library installed) --- What is the plan for loading wayland libraries? As far as I know we can't (or at least shouldn't) statically link the wayland libraries. So this means that unless you `dlopen` these, our binaries will not run on systems that lack them. The same is true for pure wayland systems of course as well. If there is not x11 libraries installed, our binary will fail to load. How do you plan to tackle this issue?

Brecht Van Lommel commented

2021-08-24 19:52:06 +02:00

I think ideally we would do two major changes:

Switch from GLEW to libepoxy or similar that can dlopen libGLX, libEGL, libGL and libOpenGL at runtime without any dependencies.
Change GHOST to make all backends (X11, Wayland, SDL) into plug-ins that we can load dynamically with dlopen depending on what is available. So then only those plug-ins need to link against Wayland or X11 libraries and Blender itself can run regardless. This would also enable Blender to run headless on servers without X11 or Wayland.

That's asking a lot from @christian.rauch of course, but maybe we really should solve all these issues for a release build.

I think ideally we would do two major changes: * Switch from GLEW to libepoxy or similar that can dlopen libGLX, libEGL, libGL and libOpenGL at runtime without any dependencies. * Change GHOST to make all backends (X11, Wayland, SDL) into plug-ins that we can load dynamically with dlopen depending on what is available. So then only those plug-ins need to link against Wayland or X11 libraries and Blender itself can run regardless. This would also enable Blender to run headless on servers without X11 or Wayland. That's asking a lot from @christian.rauch of course, but maybe we really should solve all these issues for a release build.

Sebastian Parborg commented

2021-08-25 12:15:45 +02:00

Right, I also think that those two points will require a lot of work.

This is why I initially proposed and/or asked why SDL2 had not been considered and if it had, what was the show stopper that prevented it from being a good candidate.
At least to me, SDL2 seems to have solved the issue with multiple back ends (but I could be wrong of course...).
So If we will have to do a lot of work regardless, why not switch to SDL2 and let that library do most of the platform specific heavy lifting for us?

Right, I also think that those two points will require a lot of work. This is why I initially proposed and/or asked why SDL2 had not been considered and if it had, what was the show stopper that prevented it from being a good candidate. At least to me, SDL2 seems to have solved the issue with multiple back ends (but I could be wrong of course...). So If we will have to do a lot of work regardless, why not switch to SDL2 and let that library do most of the platform specific heavy lifting for us?

Brecht Van Lommel commented

2021-08-25 12:50:47 +02:00

I don't see how SDL solves any of the specific issues we are having now? Did you see any mechanism where it helps us avoid linking the Blender executable to X11 or Wayland libraries and decide to load them at runtime only?

And as mentioned in the code review, SDL does not support all the features we need.

I don't see how SDL solves any of the specific issues we are having now? Did you see any mechanism where it helps us avoid linking the Blender executable to X11 or Wayland libraries and decide to load them at runtime only? And as mentioned in the code review, SDL does not support all the features we need.

Sebastian Parborg commented

2021-08-25 13:12:00 +02:00

In #90676#1211253, @brecht wrote:
I don't see how SDL solves any of the specific issues we are having now? Did you see any mechanism where it helps us avoid linking the Blender executable to X11 or Wayland libraries and decide to load them at runtime only?

According to this: https://wiki.libsdl.org/Installation

SDL on Unix should only link against the C runtime (glibc). Every thing else it needs will be dynamically loaded at runtime: X11, ALSA, d-bus, etc. This means it is possible to build an SDL that has support for all sorts of targets built in, and it will examine the system at runtime to decide what should be used (for example, if Xlib isn't available, it might try to load Wayland support, etc).

So to me this would solve us having to build a dymanic loading system into GHOST as SDL already have this for us.
Both X11/Wayland and GLX/EGL wise. So if we use SDL2, we don't need to implement this ourselves at all.

It also means that we don't have to implement wayland specific protocols ourselves, we can piggy back on SDL2 for that too.

In #90676#1211253, @brecht wrote:
And as mentioned in the code review, SDL does not support all the features we need.

I know you have pointed out that it doesn't support everything we need, but I don't think you gave any specific examples or gave a list of features that were missing or lacking.
From what I gather it seems like it was quite some time ago we looked at it and perhaps those issues have been fixed?

I'm not arguing that there are no issues, I just want to get a list so we can properly evaluate the pros and cons.
What I'm thinking is that if SDL2 solves this platform issue for us, then perhaps if we have any issues with it, we could fix it upstream and that would at least in the long run be a better solution.

> In #90676#1211253, @brecht wrote: > I don't see how SDL solves any of the specific issues we are having now? Did you see any mechanism where it helps us avoid linking the Blender executable to X11 or Wayland libraries and decide to load them at runtime only? > According to this: https://wiki.libsdl.org/Installation > SDL on Unix should only link against the C runtime (glibc). Every thing else it needs will be dynamically loaded at runtime: X11, ALSA, d-bus, etc. This means it is possible to build an SDL that has support for all sorts of targets built in, and it will examine the system at runtime to decide what should be used (for example, if Xlib isn't available, it might try to load Wayland support, etc). So to me this would solve us having to build a dymanic loading system into GHOST as SDL already have this for us. Both X11/Wayland and GLX/EGL wise. So if we use SDL2, we don't need to implement this ourselves at all. It also means that we don't have to implement wayland specific protocols ourselves, we can piggy back on SDL2 for that too. > In #90676#1211253, @brecht wrote: > And as mentioned in the code review, SDL does not support all the features we need. I know you have pointed out that it doesn't support everything we need, but I don't think you gave any specific examples or gave a list of features that were missing or lacking. From what I gather it seems like it was quite some time ago we looked at it and perhaps those issues have been fixed? I'm not arguing that there are no issues, I just want to get a list so we can properly evaluate the pros and cons. What I'm thinking is that if SDL2 solves this platform issue for us, then perhaps if we have any issues with it, we could fix it upstream and that would at least in the long run be a better solution.

Christian Rauch commented

2021-09-05 01:18:45 +02:00

There are a couple of topics touched here.

Runtime flags:
I agree that having this opt-in reduces the testing compared to activating this for all Wayland users at once. However, activating this at once also means that all undiscovered issues will show up for Wayland users without an easy way to start Blender with the X11 backend. This is the reason why other programs like Firefox, Chromium or SDL, activate Wayland by a runtime opt-in, and do not test this straight on their users. I strongly suggest following the same path before activating this permanently. I don't see the point of turning Wayland users into beta testers for Blender without their explicit intention.

SDL:
This came up a couple of times now. If SDL is to be used in Blender, then all of GHOST has to be replaced by SDL. It is up to Blender devs to make this call and implement it. However, SDL is a platform abstraction that will not be able to support platform-specific features. By using SDL you reduce the maintenance costs but also lose the ability to support platforms in all their detail.

EGL:

This implies that EGL might not work on nvidia cards without libOpenGL (GLVND).
Has this been tested?

I have tested Blender X11-EGL on Intel and Nvidia systems without issues.

Wayland:

What is the plan for loading wayland libraries?

I don't have a plan for dynamically loading wayland libraries. The Wayland implementation is supposed to work in the same way as the current X11 implementation, which also does not use dynamic loading via dlopen either.

How do you plan to tackle this issue?

I don't see any infrastructure in Blender for dynamic loading of GHOST implementations, so I don't intend to do something like this for Wayland. I honestly also don't see the point of doing this only for a single GHOST implementation.

I started the design document in the hope that decisions on how to go onwards would be made. What I can offer the Blender project is a Wayland implementation that works in the same way as the X11 implementation and EGL support that works in the same way as the GLX support. I am happy to continue working on the Wayland support to solve any remaining issues once this can be enabled (opt-in or opt-out) at runtime.

Regarding dynamic linking (dlopen) of windowing and OpenGL libraries or replacing GHOST with SDL, I don't see any progress in Blender towards this. As a voluntary contributor to Blender with the aim of providing Wayland support, I don't have the time or intention to contribute additional features that touch the foundation of the windowing system. I believe that these fundamental changes are tasks for core Blender developers.

There are a couple of topics touched here. **Runtime flags:** I agree that having this opt-in reduces the testing compared to activating this for all Wayland users at once. However, activating this at once also means that all undiscovered issues will show up for Wayland users without an easy way to start Blender with the X11 backend. This is the reason why other programs like Firefox, Chromium or SDL, activate Wayland by a runtime opt-in, and do not test this straight on their users. I strongly suggest following the same path before activating this permanently. I don't see the point of turning Wayland users into beta testers for Blender without their explicit intention. **SDL:** This came up a couple of times now. If SDL is to be used in Blender, then all of GHOST has to be replaced by SDL. It is up to Blender devs to make this call and implement it. However, SDL is a platform abstraction that will not be able to support platform-specific features. By using SDL you reduce the maintenance costs but also lose the ability to support platforms in all their detail. **EGL:** > This implies that EGL might not work on nvidia cards without libOpenGL (GLVND). > Has this been tested? I have tested Blender X11-EGL on Intel and Nvidia systems without issues. **Wayland:** > What is the plan for loading wayland libraries? I don't have a plan for dynamically loading wayland libraries. The Wayland implementation is supposed to work in the same way as the current X11 implementation, which also does not use dynamic loading via dlopen either. > How do you plan to tackle this issue? I don't see any infrastructure in Blender for dynamic loading of GHOST implementations, so I don't intend to do something like this for Wayland. I honestly also don't see the point of doing this only for a single GHOST implementation. --- I started the design document in the hope that decisions on how to go onwards would be made. What I can offer the Blender project is a Wayland implementation that works in the same way as the X11 implementation and EGL support that works in the same way as the GLX support. I am happy to continue working on the Wayland support to solve any remaining issues once this can be enabled (opt-in or opt-out) at runtime. Regarding dynamic linking (dlopen) of windowing and OpenGL libraries or replacing GHOST with SDL, I don't see any progress in Blender towards this. As a voluntary contributor to Blender with the aim of providing Wayland support, I don't have the time or intention to contribute additional features that touch the foundation of the windowing system. I believe that these fundamental changes are tasks for core Blender developers.

Jeremy Attali commented

2021-12-21 05:40:04 +01:00

Added subscriber: @jtheoof

Miel Truyen commented

2022-03-28 23:57:48 +02:00

Added subscriber: @Mhaus

Peter Eszlari commented

2022-04-14 20:21:34 +02:00

Added subscriber: @eszlari

Peter Eszlari commented

2022-04-14 20:21:34 +02:00

In #90676#1216115, @christian.rauch wrote:
However, SDL is a platform abstraction that will not be able to support platform-specific features.

SDL already has some platform-specific features, in v2.0.22 for Wayland too:

9c2f46b0d5

I'm sure, if a popular project like Blender needs more, they would be open to add them.

The Unreal Engine 5 editor seems to be running natively on Wayland with the help of SDL:

https://twitter.com/flibitijibibo/status/1511530172553605124

> In #90676#1216115, @christian.rauch wrote: > However, SDL is a platform abstraction that will not be able to support platform-specific features. SDL already has some platform-specific features, in v2.0.22 for Wayland too: https://github.com/libsdl-org/SDL/commit/9c2f46b0d5a5dce636522904fe0afbde78016063 I'm sure, if a popular project like Blender needs more, they would be open to add them. The Unreal Engine 5 editor seems to be running natively on Wayland with the help of SDL: https://twitter.com/flibitijibibo/status/1511530172553605124

smeikx commented

2022-04-16 23:32:44 +02:00

Added subscriber: @smeikx

Christian Rauch commented

2022-04-17 15:28:08 +02:00

In #90676#1341289, @eszlari wrote:

In #90676#1216115, @christian.rauch wrote:
However, SDL is a platform abstraction that will not be able to support platform-specific features.

SDL already has some platform-specific features, in v2.0.22 for Wayland too:

9c2f46b0d5

I'm sure, if a popular project like Blender needs more, they would be open to add them.

You cannot expect SDL to adopt every platform-specific feature for all available platforms. If you want to support a new Wayland protocol, or features like a Touch Bar or the Surface Dial, you have to implement them in SDL first. There is no guarantee that these features will be accepted upstream and if you are on a long-term platform like Ubuntu LTS or Red Hat, you have to wait years until they become available in your distribution.

The Unreal Engine 5 editor seems to be running natively on Wayland with the help of SDL:

https://twitter.com/flibitijibibo/status/1511530172553605124

Games do not really need a lot of platform-specific features. Most games just open a fullscreen window and read from mouse, keyboard or gamepad.

Anyway, I am getting a bit tired of repeating these arguments. SDL, like GHOST, is a platform abstraction. While GHOST can support arbitrary features since it is tightly coupled with Blender, SDL cannot. If you still want to replace all of GHOST with SDL, then please go ahead.

> In #90676#1341289, @eszlari wrote: >> In #90676#1216115, @christian.rauch wrote: >> However, SDL is a platform abstraction that will not be able to support platform-specific features. > > SDL already has some platform-specific features, in v2.0.22 for Wayland too: > > https://github.com/libsdl-org/SDL/commit/9c2f46b0d5a5dce636522904fe0afbde78016063 > > I'm sure, if a popular project like Blender needs more, they would be open to add them. You cannot expect SDL to adopt every platform-specific feature for all available platforms. If you want to support a new Wayland protocol, or features like a Touch Bar or the Surface Dial, you have to implement them in SDL first. There is no guarantee that these features will be accepted upstream and if you are on a long-term platform like Ubuntu LTS or Red Hat, you have to wait years until they become available in your distribution. > > The Unreal Engine 5 editor seems to be running natively on Wayland with the help of SDL: > > https://twitter.com/flibitijibibo/status/1511530172553605124 Games do not really need a lot of platform-specific features. Most games just open a fullscreen window and read from mouse, keyboard or gamepad. Anyway, I am getting a bit tired of repeating these arguments. SDL, like GHOST, is a platform abstraction. While GHOST can support arbitrary features since it is tightly coupled with Blender, SDL cannot. If you still want to replace all of GHOST with SDL, then please go ahead.

Pipeliner commented

2022-05-24 14:36:45 +02:00

Added subscriber: @Pipeliner

Eric Engestrom commented

2022-06-17 09:01:16 +02:00

Added subscriber: @1ace

Archer Allstars commented

2022-07-07 17:19:11 +02:00

Added subscriber: @archerallstars

VitalyR commented

2022-08-15 04:51:54 +02:00

Added subscriber: @VitalyR

Campbell Barton commented

2022-12-08 05:21:05 +01:00

Could this task be closed now? It looks like issues raised in this task have been resolved.

Christian Rauch commented

2022-12-09 18:03:16 +01:00

Changed status from 'Needs Triage' to: 'Resolved'

Christian Rauch closed this issue

2022-12-09 18:03:16 +01:00

Christian Rauch self-assigned this 2022-12-09 18:03:16 +01:00

Christian Rauch commented

2022-12-09 18:03:16 +01:00

In #90676#1456493, @ideasman42 wrote:
Could this task be closed now? It looks like issues raised in this task have been resolved.

Yes. The main questions regarding the OpenGL linking and Wayland support have been resolved. I think there are some open issues with the OpenGL context creation in OpenSubdiv, but this is not so much related to the issues discussed here.

> In #90676#1456493, @ideasman42 wrote: > Could this task be closed now? It looks like issues raised in this task have been resolved. Yes. The main questions regarding the OpenGL linking and Wayland support have been resolved. I think there are some open issues with the OpenGL context creation in OpenSubdiv, but this is not so much related to the issues discussed here.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Wayland support #90676

1 Introduction

1.1 Motivation

1.2 OpenGL Context

1.2.1 Legacy

1.2.2 Modern

2 Current State

3 Proposed Solution

3.1 GHOST

3.2 OpenGL Context

4 Experimental Builds