Gaming Linux® From Scratch (System V Edition) - Version #05cf

Chapter 8. Graphics Drivers

About OpenGL

What is OpenGL?

OpenGL is a fairly high-level 3D graphics API. Its specification is defined by Khronos Group, and implemented by different vendors. Mesa was the first big one that implemented the specification.

The implementation got tied to window systems (and thus led to several implementations) and drivers limited to those inside Mesa's architecture. The main issue with this is that the core OpenGL libraries [3] contained the implementations of OpenGL. Drivers outside of Mesa who weren't in the project for any given reason had to fit into their architecture or replace the core libraries with their own.

NVIDIA, after trying to fit into their architecture, decided to create new core OpenGL libraries based on aritger's new OpenGL ABI proposal. The libglvnd project was the result, which contains core OpenGL libraries that properly dispatch each API call to an OpenGL driver's implementation of it. No driver had to fit into an a specific architecture dictated by the core OpenGL libraries anymore. This led to multiple issues once the mass transition was done.

libOpenGL

Mesa is able to provide:

  • libGL

  • libGLX

  • libEGL

  • libGLESv1_CM

  • libGLESv2

libGL is tied to libGLX. This is a minor problem with windowing systems that aren't Xorg and the general goal to have a system without Xorg/GLX. libglvnd thus provides libOpenGL which isn't tied to any window system. Build systems checking for OpenGL tend to choose libOpenGL over libGL. The built result in that case will be linked against libOpenGL. Trying to run it on a system with Mesa's core OpenGL libraries installed will lead to failure.

In most cases, if libOpenGL is not found while building a project, libGL is chosen instead. However, in some projects supporting Wayland, the build system will refuse to configure. This is because some build systems don't like combining libGL with libEGL.

Different Sonames

A soname is the field after a library (shared object)'s file extension. An example is libGL.so.1. After libGL.so is .1. 1 would be the soname. When an application or library is linked against a library, it links against the name of the library with the soname. When the only existing library on the system has a different soname, the software will fail to work as the library cannot be found.

The sonames of Mesa and libglvnd's core OpenGL libraries differ, especially in the case of libGLX. Most binaries are linked against libglvnd's core OpenGL libraries, so the sonames they expect will often differ from Mesa's core OpenGL libraries. AppImages tend to fall into this.

The Stance of Most Linux Distributions, BLFS, GLFS, and SLFS

Most Linux distributions have already switched to libglvnd. Some distributions, like in the case of Debian, also provide Mesa's core OpenGL libraries. Thus, the user has an option in those cases. Most cases won't be like that. The general stance based on majority is that libglvnd is now the standard OpenGL vendor for Linux.

This has been the case for multiple years. BLFS has been an outlier in that it does not have libglvnd, does not incorperate instructions to allow libglvnd, and only supports Mesa. Attempts to get this changed have been turned down. The stance that will stand for at least a couple years into the future will be that BLFS will not support libglvnd. As a result, this causes issues for libglvnd users.

Despite how BLFS does not support libglvnd, this book and Supplemental LFS [4] support and prefer libglvnd over Mesa's core OpenGL libraries. The issues laid out in the previous section pose issues that occur in this book and in SLFS, and for users of this book. Mesa's core OpenGL libraries severely limit the amount of software a user can run.

You can still install Mesa's core OpenGL libraries if you wish, but will run into issues outside of BLFS. The choice is up to you. Instructions are provided for each route, but the default instructions set up for libglvnd.

[Important]

Important

Switching between vendors is not recommended. You should choose very carefully on which vendor to install from. If you want to switch, it might be best to rebuild the system due to linking and runtime issues.

About GLES (OpenGL ES)

What is GLES?

GLES, or OpenGL ES, or OpenGL for Embedded Systems, is what the full name suggests: it is a stripped down version of OpenGL, a subset, with a slightly different API here and there. It is used mostly for devices with ARM chips such as smart phones and tablets, but is also used in gaming consoles. On the Linux desktop, you typically have desktop, or full, OpenGL, EGL, GLX, and GLESv{1,2,3}.

GLES, specifically v2 and v3, are used sometimes, but mostly in one area: in Wayland compositors and compositor libraries. These include Hyprland, Mutter, Wayfire, and Wlroots. While compositors can utilize Vulkan, most compositors require GLES rendering and don't offer a Vulkan solution, or any other rendering API solution. GLESv1 on the otherhand is an outdated specification of the GLES API that has been phased out for many years. This book disables building for GLESv1 as it is deprecated. You may build the API spec if you wish.

History of Wayland and GLES

When the Wayland set of protocols were made, a reference implementation had to be made for it to show what was possible, and how to create a compositor for the new protocol. The result was Weston. For its rendering API, it used, and uses, GLES and EGL. This was done so that the dependency on the libraries from the X Window System wasn't needed, that a Wayland-only setup was possible. A small benefit of using GLES was that it could run on embedded systems like Raspberry Pis.

Thus, compositors and compositor libraries followed suite and did the same thing. However, any rendering API can be used as long as it can be put through EGL. Desktop OpenGL and Vulkan can be used with no issues. Today, the situation is the same and most compositors don't accept any other rendering API besides GLES.

Do I need GLES?

If you are wanting to use Wayland compositors, and are going to use one that does not support Vulkan rendering, you are very likely going to have to build GLES v2 and v3, or else OpenGL and EGL rendering will not be an option. There are very few Wayland compositors that support Vulkan and do not require GLES. If you do find one, like dwl, you won't really need GLES beyond compositing. Wayland clients, which are applications, will typically just use OpenGL and/or Vulkan with EGL. This means that you would be able to skip GLES support but would kill off the ability to use other Wayland compositors that require GLES rendering.

On the otherhand, if you are using the X Window System, GLES will almost never be used and that support for the API can be disabled without much worry. However, you kill off the ability to use Wayland compositors that require GLES rendering if you want to switch over to Wayland in the future.

Disabling GLES

If you decided to disable GLES support, it is pretty easy to not build in support for the API. In “Command Explanations”, for both libglvnd-1.7.0 and Mesa-25.2.2, they will explain the options required to disable the support. Furthermore, NVIDIA-580.95.05 installs drivers for GLES. The installation instructions for that driver will cover how to delete them if you do not need GLES.

If you already have installed GLES from any of the OpenGL providers, removing all the related files is pretty easy. You can follow the instructions below as the root user to remove the API: 

for libdir in /usr/lib*; do
  rm -vf  $libdir/pkgconfig/gles*
  rm -vrf /usr/include/GLES*
  rm -vf  $libdir/libGLES*
done
ldconfig

Recompile any packages as necessary to remove the dependency on GLES.

If you have decided to revert your decision and wish to build support for GLES, just recompile OpenGL from the original OpenGL provider you went with without the option needed to disable GLESv2. You can however keep the option to disable GLESv1 as v1 is an outdated spec and not needed today.


[3] libGL, libGLX, etc.