3

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.

timday
  • 705
  • 1
  • 9
  • 18

3 Answers3

2

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;

http://minkirri.apana.org.au/wiki/DevJournal

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.

Donovan Baarda
  • 121
  • 4
  • 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
  • The tigervncserver (NB that's "tiger" not "tight") which has appeared in Debian9 (stretch) appears to be a VNC server with such GLX support. Also some other modern innovations like pushing users in the direction of ssh tunneling rather than naked VNC protocol over the wire. See https://unix.stackexchange.com/a/395388/5094 – timday Dec 19 '17 at 16:16
2

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.

Update: From Debian9 ("Stretch") I switched to using tigervncserver (new in Debian stable in this release I think; via the tigervnc-standalone-server package) instead of virtualgl. See the other answer.

timday
  • 705
  • 1
  • 9
  • 18
1

I see that in Debian9 ("stretch") something called tigervnc-standalone-server has appeared. This appears to include some OpenGL support (I note mesa is a dependency). I had no problems installing it on a fresh Debian9 install and firing it up got me a VNC-able (any VNC client) standalone (not "screen scraped") desktop running Gnome (no messing around with .Xsession files needed) which seems to have no problems running evolution or glxgears. No virtualgl needed or even installed on the machine. Very nice! (Although I strongly suspect this solution is probably using SW rendering, whereas with virtualgl I was using the GPU; for primarily 2D desktop apps on modern CPUs, this is just fine though).

Note that the tigervnc server doesn't accept remote (non-localhost) connections by default (although there is a commandline option to override that); this is supposed to (sensibly) encourage you to use ssh tunnelling!

timday
  • 705
  • 1
  • 9
  • 18