Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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

1 Answer 1

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.

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.