Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

For many years I've been in the habit of, when away from home, VNC-ing (over ssh) back into my "home machine" and running Evolution (for email, contacts etc) in a tightvncserver environment there.

This worked fine when the home machine was running Debian/Squeeze, but now it's been updated to Wheezy, attempting to start Evolution in the VNC server session outputs:

Xlib:  extension "GLX" missing on display ":1".
Failed to connected to any renderer:
XServer appears to lack required GLX support

tightvncserver not supporting GLX isn't a surprise, but Evolution moving to a GL backend (through its use of the "clutter" toolkit?) is. (Just to be clear: Evolution works absolutely fine on the desktop; the machine has the nvidia drivers via DKMS.)

What are the prospects for working round this? I'm thinking along the lines of:

  • Is there a command line option to Evolution which will fix this?
  • Is there some way of getting GLX support in a VNC server? (Alternatives to tightvncserver which support it?)

Note that I tend to be VNC-ed in over high-latency/low-bandwidth links; I've tried running Evolution remotely over X11 before and it's not a good experience; VNC works much better.

Debian-friendly (apt-get -able) solutions preferred.

share|improve this question

I've battled the same problem trying to get qtcreator working over vnc and eventually figured out why it wasn't working, and how to fix it;


You don't need VirtualGL, and it might even be worse than the alternatives. Importantly, you can make it work just using standard Debian packages.

VirtualGL is for app-server side hardware acceleration. GLX is for x-server side hardware acceleration. When using VNC normally the app-server and the x-server are on the same machine along with your vnc-server, so there is not much difference between VirtualGL and GLX.

The problem is the two most common vnc-servers tightvncserver and vnc4server are both x-proxy servers with their own internal x-server that doesn't support GLX. You can still make 3D applications work with them, but you need to use old-school app-server side software rendering, which means you need libgl1-mesa-swx11 installed on your app-server, and this conflicts with the normally installed hardware rendering version libgl1-mesa-glx.

Alternatively you can install a normal x-server with hardware rendering GLX support and use x11vnc, which is a vncserver that screen-scrapes a real x-server.

It would be nice if someone wrote a new x-proxy vnc-server with proper GLX support using libvncserver (used by x11vnc). Both tightvncserver and vnc4server are getting a bit crusty.

share|improve this answer
Nice write up at your link; thanks for sharing. Yes it's a VNC server with decent GLX support would be an ideal fix IMHO, especially with more and more Linux-world GUI apps seem to be adopting OpenGL-based toolkits (e.g Qt5 heavily depends on OpenGL). Good tip about libgl1-mesa-swx11, although I do like the fact VirtualGL means I get HW accel (not that I've ever tried to assess the benefits in the VNC access setup). – timday Oct 31 '14 at 23:43
up vote 0 down vote accepted

After a little more research, all roads appear to lead to VirtualGL (docs), although I have yet to try it (setup instructions are somewhat... intimidating). The documentation points to some .debs, and there is an open ITP for Debian.

As an alternative, it seems it may be possible to build a tightvncserver with GLX support via Mesa (e.g mention here). That wouldn't be GPU accelerated of course (but how much graphics horsepower can email need???); of more concern is that (at least last time I tried), Debian wouldn't let you have more than one set of OpenGL libs installed on a machine at a time, and I wouldn't want to give up HW acceleration for local use.

I'll update here if I have any success one way or the other; I'm certainly still interested in any other (possible) solutions/pointers.

Progress: Installing VirtualGL via the appropriate .deb and following the instructions (not as bad as they first look; the coverage of a multitude of platforms bulks them up somewhat) gets me (HW accelerated!) GLX support in a tightvncserver. That's the first time I've seen that!

/opt/VirtualGL/bin/vglrun glxgears

enter image description here

Evolution does also work via this mechanism, solving my main problem.

However, there are some significant issues with this method. It only works when someone is logged in to the host machine (and not when the gdm3 "greeter" is displaying, in which case vglrun obtains a "could not open display:0" error), and any sort of display transition (for example someone ctrl-alt-Fn-ing to a virtual console) will kill the vglrun app with a "Could not Read Pixels" error). Screen-locking seems OK though. For my purposes, I can live with this (there is someone else who is primary user of the machine I'm VNCing into, and they're always logged in and most unlikely to do anything as technical as a ctrl-alt-Fn away from the desktop), but it may not be ideal for others.

Update: actually, there is a fix enabling VNC+GLX use while the gdm3 "greeter" is showing. Simply drop a xhost +LOCAL: line near the start of /etc/gdm3/Init/Default. The vglserver_config script does actually attempt to do this (for insecure setups), but it doesn't know anything about gdm3's configuration files (it does check for gdm and xdm though). Although note that what would be better (and what the config script tries to do, assuming you've gone for the more secure options during setup, with the vglusers group) is to have a vglgenkey there instead, but this doesn't seem to do anything (doesn't create a /etc/opt/VirtualGL/vgl_xauth_key as its supposed to).

Update: Actually, creation of a /etc/opt/VirtualGL/vgl_xauth_key for gdm3 can be enabled by adding the Debian-gdm user to the vglusers group. But that just moves the problem elsewhere with vglrun now complaining about being unable to lock something in /var/run/gdm3/ (which has permissions root:Debian-gdm). I'm out of my depth at this point and the no doubt horribly insecure xhost +LOCAL: line will have to do.

Update: Just got around to updating this crufty old Debian machine from Wheezy to Jessie, and updated to virtualgl 2.5 debs from SourceForge. vglrun evolution working great once the server is configured with vglrun_config.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.