Home » Linux » OpenGL without X.org in linux

OpenGL without X.org in linux

Posted by: admin November 30, 2017 Leave a comment


I’d like to open an OpenGL context without X in linux. Is there any way at all to do it?

I know it’s bossible for integrated intel graphics card hardware, though most people have nvidia cards in their system. I’d like to get a solution that works with nvidia cards.

If there’s no other way than through integrated intel hardware, I guess it’d be okay to know how it’s done with those.

X11 protocol and protocol itself is too large and complex. Mouse/Keyboard/Tablet input multiplexing it provides is too downwatered for modern programs. I think it’s the worst roadblock that prevents linux desktop from improving, which is why I look for alternatives.


Update (Sep. 17, 2017):

NVIDIA recently published an article detailing how to use OpenGL on headless systems, which is a very similar use case as the question describes.

In summary:

  • Link to libOpenGL.so and libEGL.so instead of libGL.so. (Your linker options should therefore be -lOpenGL -lEGL
  • Call eglGetDisplay, then eglInitialize to initialize EGL.
  • Call eglChooseConfig with the config attribute EGL_SURFACE_TYPE followed with EGL_PBUFFER_BIT.
  • Call eglCreatePbufferSurface, then eglBindApi(EGL_OPENGL_API);, then eglCreateContext and eglMakeCurrent.

From that point on, do your OpenGL rendering as usual, and you can blit your pixel buffer surface wherever you like. This supplementary article from NVIDIA includes a basic example and an example for multiple GPUs. The PBuffer surface can also be replaced with a window surface or pixmap surface, according to the application needs.

I regret not doing more research on this on my previous edit, but oh well. Better answers are better answers.

Since my answer in 2010, there have been a number of major shakeups in the Linux graphics space. So, an updated answer:

Today, nouveau and the other DRI drivers have matured to the point where OpenGL software is stable and performs reasonably well in general. With the introduction of the EGL API in Mesa, it’s now possible to write OpenGL and OpenGL ES applications on even Linux desktops.

You can write your application to target EGL, and it can be run without the presence of a window manager or even a compositor. To do so, you would call eglGetDisplay, eglInitialize, and ultimately eglCreateContext and eglMakeCurrent, instead of the usual glx calls to do the same.

I do not know the specific code path for working without a display server, but EGL accepts both X11 displays and Wayland displays, and I do know it is possible for EGL to operate without one. You can create GL ES 1.1, ES 2.0, ES 3.0 (if you have Mesa 9.1 or later), and OpenGL 3.1 (Mesa 9.0 or later) contexts. Mesa has not (as of Sep. 2013) yet implemented OpenGL 3.2 Core.

Notably, on the Raspberry Pi and on Android, EGL and GL ES 2.0 (1.1 on Android < 3.0) are supported by default. On the Raspberry Pi, I don’t think Wayland yet works (as of Sep. 2013), but you do get EGL without a display server using the included binary drivers. Your EGL code should also be portable (with minimal modification) to iOS, if that interests you.

Below is the outdated, previously accepted post:

I’d like to open an OpenGL context without X in linux. Is there any way at all to do it?

I believe Mesa provides a framebuffer target. If it provides any hardware acceleration at all, it will only be with hardware for which there are open source drivers that have been adapted to support such a use.

Gallium3D is also immature, and support for this isn’t even on the roadmap, as far as I know.

I’d like to get a solution that works with nvidia cards.

There isn’t one. Period.

NVIDIA only provides an X driver, and the Nouveau project is still immature, and doesn’t support the kind of use that you’re looking for, as they are currently focused only on the X11 driver.


You might be interested in a project called Wayland



Just use Mesa.


Have you looked at this page?

It is likely a bit outdated. I haven’t tried yet, but I would appreciate more documentation of this type.

Probably a good idea, as of today, is to follow Wayland compositor-drm.c implementation:


You can look at how Android has solved this issues. See Android-x86 project.

Android uses mesa with egl and opengles. Android has its own simple Gralloc component for mode setting and graphic allocations. On top of that they have SurfaceFlinger component which is a composition engine, which uses OpenGLES for acceleration.

Cannot see why couldn’t you use these components in similar way and even reuse the Android glue code.