A tale of Debian, Mesa, and ancient OpenGL

5 minute read


Sometimes, software changes and bug fixes can have unintended consequences. Usually this results in things breaking. However, rarely it can result in things working when you least expect it. This tale is about both of these situations.

Specifically, this tale is about OpenGL ES v1.1 on Debian.

What is OpenGL ES v1.1?

OpenGL ES v1.1 is a modified subset of OpenGL v1.3 for mobile devices. In other words, it sucks. Mainly, because:

  • It lacks many desktop OpenGL features.
  • It is fixed-function only, no shaders at all!
  • It is ancient. (Released in 2003!)

But like many terrible technologies, sometimes you have to use them anyway.

In my case, I maintain a modding project for a game that uses OpenGL ES v1.1. Normally, I use a compatibility layer that ports the game to OpenGL ES v2, but I wanted to make sure the project worked without it. And that is where this tale begins.

December 2023: I encounter an unusual error

It was December 25th, 2023, and I was ready to test my project. I had quickly built a version without the compatibility layer. However, when I started it, I was blindsided by the most peculiar error:

GLX: Failed to create context: BadAlloc (insufficient resources for operation)

This error made no sense! My laptop had 32 GB of RAM and was nowhere near running out!

I tried everything I could think of:

  • I tried running a bare-bones OpenGL ES v1.1 demo program1.
  • I tried using EGL instead of GLX.
  • I double-checked that libgles1 was installed correctly.
  • I tried using EGL with debug logging.

But nothing worked.

Ultimately, I concluded this was probably a bug in Mesa. Especially since it had worked perfectly before I upgraded to Ubuntu 23.10. Oh, how naive I was.

So, I built a copy of upstream Mesa (using the same version as Ubuntu), ran the OpenGL ES v1.1 test program, and… it worked?

Hours of testing later, I eventually understood why Ubuntu 23.10 broke OpenGL ES v1.1. And to explain that, we have to go all the way back to 2017!

February 2017: Debian disables OpenGL ES v1.1 support in Mesa

On February 2nd, 2017, Debian disabled OpenGL ES v1.1 support in the Mesa package. I do not know why it was disabled, because no explanation was given in either the Git commit or the associated change-log2. But --disable-gles13 was added to the Debian package regardless.

This might seem like it explains my situation, except for one crucial detail: OpenGL ES v1.1 had worked perfectly on distributions like Debian Bookworm and Ubuntu 23.04, both of which had included this change.

For some reason, this change had not actually disabled OpenGL ES v1.1!

My question had changed from “why is OpenGL ES v1.1 not working” to “why was OpenGL ES v1.1 working in the first place?”

The answer to that comes only one year later.

August 2018: Enter GLVND

Fun (and relevant) fact: if you use Debian, many OpenGL-related shared libraries (like libGL.so.1, libOpenGL.so.0, libGLESv2.so.2, libEGL.so.1, and many more) are not actually provided by your graphics driver. Instead they are provided by a project called GLVND. GLVND’s job is to provide a driver-agnostic OpenGL interface, that then forwards any API calls to your actual driver. This is beneficial for reasons beyond the scope of this blog post.

Anyways, on August 8th, 2018, OpenGL ES v1.1 support was enabled in Debian’s GLVND package4. Reading the linked Launchpad bug is actually quite interesting because:

  • It seems the maintainers believed that Mesa itself no longer supported OpenGL ES v1.1, which is patently false.
  • And it reveals that OpenGL ES v1.1 support was enabled in GLVND anyways to support non-Mesa drivers (like NVIDIA’s5).

Debian’s use of GLVND interacted with a quirk of Mesa’s build-system in a really interesting way: you see, --disable-gles1 did not actually disable OpenGL ES v1.1. Instead it only disabled building the libGLESv1_CM.so.1 library, Mesa itself still included support for OpenGL ES v1.1. But Debian systems did not need Mesa’s libGLESv1_CM.so.1 because GLVND provided one!

So GLVND’s libGLESv1_CM.so.1 forwarded API calls directly to Mesa, completely bypassing the effects of --disable-gles1! Therefore, OpenGL ES v1.1 worked. Completely. By. Accident.

But it did not just work. It worked well. In fact, there was no sign that it was not supported!. All you had to do was install libgles1 and it just worked.

Now that I knew why OpenGL ES v1.1 used to work, I could finally answer my first question: why did it stop working?

May 2023: Mesa makes an objectively good change

Remember when I said “--disable-gles1 did not actually disable OpenGL ES v1.1?” Well, that was past-tense for a reason.

On May 19th, 2023, Mesa 23.1.0 was released. And among its many changes, it made --disable-gles1 actually remove the associated code. This version of Mesa was eventually included in Ubuntu 23.10 and Debian Trixie.

This is what broke OpenGL ES v1.1. Now that Mesa properly disables OpenGL ES v1.1, the GLVND workaround is broken.


This situation annoyed me for multiple reasons. It annoyed me that OpenGL ES v1.1, which appeared to be fully supported, was actually only working by chance and had been unsupported for years. It annoyed me that Debian dropped support for OpenGL ES v1.1 seemingly without an explanation. And it really annoyed me that almost none of this information was written down anywhere accessible!

But ultimately, the damage has been done.

There is no reason for Mesa to revert what truly is a good change. Making disabling OpenGL ES v1.1 actually remove the associated code is the sensible thing to do. So the GLVND workaround is well and truly dead.

And considering that almost nobody uses OpenGL ES v1.1, I highly doubt Debian will ever re-enable it.

So, here we are. If you want to use OpenGL ES v1.1 on Debian, get ready to compile Mesa from source. It sucks, but at least it’s documented now.

  1. If you run Mesa’s es2_info with executable name es1_info, it will actually switch to OpenGL ES v1.1 mode. 

  2. There might be one buried in Debian’s enormous bureaucracy, but I would not know how to look for it. 

  3. This became -Dgles1=disabled when Mesa switched to Meson. 

  4. This is what any modern Debian system’s libgles1 package is. 

  5. NVIDIA’s proprietary driver actually does include OpenGL ES v1.1 support. It shocked me too.