38
votes

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 possible 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 itself is too large and complex. Mouse/Keyboard/Tablet input multiplexing it provides is too watered-down for modern programs. I think it's the worst roadblock that prevents Linux desktop from improving, which is why I look for alternatives.

5
@nos: libSDL adopts the same limitations X11 imposes. For example: The wacom tablet gets limited into display resolution, while that tablet itself has ten times larger resolution than the display has! Large dpi mice have similar problems I've heard.Cheery
"X11 protocol ... is too large and complex." Maybe, but have you seen an insanely popular alternative to X that is supported by ATI/NVidia? My advice is to stick with whatever is available and supported, whether you like it or not. Besides, you don't have to deal with X directly. There are cross-platform libraries like SDL(games) and Qt 4 (for gui). If you don't like X, use higher level API. When X will be replaced by something else, your API will be updated, and you won't have to rewrite everything. It's like WinAPI on windows - it is still available, but you don't have to use it directly.SigTerm
@Cheery: Now, about your question, see this: superuser.com/questions/115330/… . If you want to try making a desktop environment, I'd recommend to make Game GUI system with SDL. Will be pretty close to the "real thing", without all the troubles. Keep in mind that even if you make an decent X alternative, it will take years until it becomes adopted.SigTerm
Transparent networking is a niche most people do not ever need. If you'd really need such thing, you'd be using plan9.Cheery
Qt 4 has "QWS" which is a virtual framebuffer that does not require X11 and does support OpenGL. Worth giving it a try I guess.bparker

5 Answers

37
votes

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.

8
votes

You might be interested in a project called Wayland

http://en.wikipedia.org/wiki/Wayland_%28display_server%29

4
votes

Have you looked at this page? http://virtuousgeek.org/blog/index.php/jbarnes/2011/10/31/writing_stanalone_programs_with_egl_and_

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: http://cgit.freedesktop.org/wayland/weston/tree/src/compositor-drm.c

3
votes

https://gitlab.freedesktop.org/mesa/kmscube/ is a good a reference implementation of OGL (or OGLES) hardware-accelerated rendering without an X11 or wayland dependency.

1
votes

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.