Hi there
How about some GPU hardware accelerated graphics so you can run more demanding 3D OpenGL applications?
After first using ThinLinc, I had the idea: What if I could play some games on my remote session? And how about some video editting? That’s when I learned about VirtualGL, and then I could run (and play) some games with proper configuration. Other OpenGL programs that depend on hardware accelerated graphics also may start working fine. I had some problems to get it running at first, so here’s this guide to help you save some time by not doing the same mistakes I did 
VirtualGL setup (and advice!)
Ok, so, now that you got a ThinLinc Server up and running and that’s great. But you try to open a more demanding graphical application and you get an undesirable result: Unplayable FPS in games, graphical applications refusing to start because no compatible GPU was found… and there is a workaround for some of those applications. The OpenGL graphical applications may benefit from another software named VirtualGL, that lets your remote machine render the graphics on its GPU and send you a better quality result instead of software rendered graphics. While software rendered graphics are enough for videos for example, demanding graphical applications won’t run remotely if you don’t have VirtualGL working on your machine.
Since this tutorial is based on my openSUSE Tumbleweed KDE installation guide (check HERE - openSUSE Tumbleweed KDE ThinLinc Install Guide) out-of-the-box, some instructions may differ for your distro, but I’m going to detail the installation process for you and help you avoid some of my mistakes! Also, VirtualGL on openSUSE Tumbleweed repo is on version 2.6.5-1.8 and version 3.0 is out since last November, may be I’ll try this newer version after and notify you if there’s some important note to add. I thought that it’d be easy to get a fresh installed system running a common desktop environment such as KDE and install ThinLinc and VirtualGL on it, but it was my first mistake: I previously installed on openSUSE Leap running LXDE and it was a piece of cake to get ThinLinc Server running because no sshd symlink was needed and the GTK+ dependencies were there. When I first installed it on Tumbleweed, I had trouble figuring out that some needed files had moved… VirtualGL was even harder because it worked fine on my Tumbleweed LXDE, but has been more trouble to get it running on KDE.
Also, I’ve written this guide using an AMD GPU. If you’re using a nVidia GPU, you also need to install nVidia’s proprietary drivers. Refer to your distro how to install it.
One more advice… You only have to install VirtualGL on the ThinLinc Server. The clients don’t need nothing else.
Let’s cut the chat and get going.
-
The VirtualGL package on openSUSE Linux is easy to install because it is part of the distro’s main repo (OSS). Just “zypper in VirtualGL” as root and done. In My openSUSE Tumbleweed, I also installed the 32-bit package, but I think that just VirtualGL package should be enough (Leap for example doesn’t have the 32-bit option anymore). VirtualGL32-bit is needed if you want to run 32-bit applications). VirtualGL website provides packages for some distros that don’t have VirtualGL on their repositories. For them, VirtualGL will be installed on /opt folder.
-
I could continue with VirtualGL configuration, but then you wouldn’t be able to get it running just like I did and struggled for some hours to figure out what was happening. So, please pay attention to this information written on VirtualGL’s website about oficial support: VirtualGL | Documentation / VirtualGL Operating System Support Policy - It mentions that it officially supports GDM and LightDM. Also, I’ve found some other people that had problems using VirtualGL and SDDM (KDE’s default login manager). That said, when using SDDM, VirtualGL simply did not work for me and the most simple solution was to install LightDM, uninstall and add a lock to SDDM (to prevent it from being reinstalled after an update). You may use some others instead of LightDM, but please refer to VirtualGL Documentation to see if your login manager is supported and if there is additional configuration. For this guide, let’s install lightdm with “zypper install lightdm” as root. For other distros, refer to your package manager how to install it:
-
Remove sddm with “zypper remove sddm” as root (or if you were using another login manager, replace sddm with the one you were using. And refer to your distro package manager if you’re not using openSUSE):
(optionally you may also run “zypper addlock sddm” after removal to prevent it from being reinstalled.)
-
Now reboot your system so we can continue with LightDM and get rid of SDDM.
-
After rebooting, we need to configure VirtualGL. And that is another part of my struggle, because whenever I tried to configure it, if LightDM was not stopped, I would not be able to use VirtualGL through ThinLinc even after a system reboot! So, the best advice is: Ctrl+Alt+F1 to jump to tty1 (terminal mode), login and run “init 3” or “service lightdm stop” before running the VirtualGL configuration tool. This recommendation is written in official VirtualGL documentation: User’s Guide for VirtualGL 3.0 . The command “init 3” will change the system from “Networking/Multitasking/GUI” mode to the “Networking/Multitasking/Command Line only”, in other words, it will stop LightDM and the graphical environment.
-
And now, run vglserver_config as root:
There are few options to configure after running vglserver_config. First choose 1 (Configure). Then, for our example, I’m going to use the recommended options: Restrict to vglusers group and disable XTEST. For more information about what those settings mean, read the VirtualGL’s official documentation here - User’s Guide for VirtualGL 3.0
-
Now that you ran vglserver_config with graphical mode stopped, you may restart the graphical environment by running the command “init 5” or “service lightdm start”. Rebooting the system is also an option.
-
Since I’ve restricted access to vglusers group, I have to set my user to be part of that group. On openSUSE, go to "Users and Groups Management’’ on YaST or manually edit /etc/group and add your users to the vglusers group.
edit the desired user
on Details tab, select vglusers and click OK
should appear like this on YaST.
OR you may manually edit /etc/group and add your users to vglusers group. Here’s how the file should be after editing:
You can verify if the user is in a group by using groups command:
Remember that after adding an user to a group, you must logout and then login for changes to take effect.
- Now that you stopped graphical environment, installed lightdm, removed sddm, ran vglserver_config, user is in vglusers group (if you restricted to it) and restarted the graphical mode, VirtualGL should be working. Let’s test it!
Testing if everything is working fine
The easiest way to test is to go to another computer on the same network, install ThinLinc client, connect to the ThinLinc server and run “vglrun glxspheres” to check if it’s rendering on the GPU instead of software (llvmpipe). If you were configuring it remotely through SSH and your machine is behind a NAT, you should read the “How about the ThinLinc Client? How do I access my ThinLinc Server?” section in this guide. The glxspheres command is part of VirtualGL, if you don’t know where it is (i.e. it’s not on your PATH, check the VirtualGL install folder)
-
Open your ThinLinc Client in another computer and input the server address, username and password:
-
You should see the ThinLinc’s welcome screen:
If you instead only see a blue screen like below and then you log in to the system, possibly it means that you didn’t install the GTK+ Dependencies for your ThinLinc Server
I don’t know if there are some other problems, but if you want to fix it, refer to the ThinLinc Server installation guide that I’ve written.
-
You now are remotely connected to your ThinLinc Server
-
To check if VirtualGL is working, open a terminal and run “vglrun glxspheres” (it should’ve been installed along with VirtualGL).
If your GPU name appears on the “OpenGL Renderer” and you get a good Mpixels/sec rate, VirtualGL is up and running.
What if it’s not working?
I’ve been through this and it took me some time to figure out what was wrong. Here are some screens that represent that something is wrong. If you can reproduce some of them, maybe you have to check if everything was installed according to this guide.
-
Missed to install GTK+ Dependencies for ThinLinc: You’re not going to be able to run Click to Install.desktop and use GUI Installer and you’re not going to see the ThinLinc’s Welcome screen. To fix it, refer to step 9 on the ThinLinc Server Installation CLI or step 2 on the ThinLinc Server Installation GUI on this guide. This has nothing to do with VirtualGL, it’s more like a reminder from the ThinLinc installation guide on openSUSE Tumbleweed KDE.
-
vglrun glxspheres seems to hang and no error or spheres are shown:
I had this behavior and figured out that it was because the physical ThinLinc Server machine was on TTY1 instead of showing the graphical login screen! It is funny because ThinLinc will work fine, but vglrun is not going to show you the image until you go to the ThinLinc Server physically and hit CTRL+ALT+F7 (or whatever FKey is your graphical login screen. Glxspheres would continue as soon as you change the ThinLinc server to the local graphical login screen and if you switch it back to the terminal, glxspheres will continue fine… but won’t close if you don’t put the ThinLinc server back on the Graphical login screen. I’m not sure why, maybe changing the options at vglserver_config would allow a remote user to run graphical applications on VirtualGL while the local machine is at a terminal screen. VirtualGL has a small guide for headless nVidia servers that maybe can fix this behavior, but I’m not sure. If you need the ThinLinc Server machine to be accessed physically through a terminal screen such as TTY1 while other users are remotely accessing it, check VirtualGL documentation or ask their maintainers. For now, leave your ThinLinc Server on the graphical login screen: (example for default LightDM screen on openSUSE)
- vglrun could not open display
VirtualGL relies on the DISPLAY variable to send the image to the right screen. If it says that it cannot open display, and it has no authorization, check if:
- DISPLAY variable is correct (echo $DISPLAY);
- user is in vglusers group (groups username);
- vgl_auth_key file exists (cat /var/lib/VirtualGL/vgl_xauth_key);
(The vgl_auth_key also may be at /etc/opt/VirtualGL/vgl_xauth_key for other distros).
For this error, there are different causes:
- I thought at first that simply exporting the DISPLAY variable could fix the problem, but then I realized that this problem occurs more often if you are logged in locally and then start a remote ThinLinc Session. Starting a remote ThinLinc session while you’re also logged in locally may result that the DISPLAY variable points to the wrong place, but also means that if you try to open an application that has a lock (firefox for example) will result in an error. If that’s the case, run “vglxinfo | head” to get the right display and export the correct value (export DISPLAY=:value). I don’t recommend logging in remotely while connected locally because such minor problems should happen.
There is a “-d” option in vglrun that may change the display output for that command, but pay attention that it may trick you into believing that everything is fine, but instead it is not rendering on the GPU, but into software instead. The screen below shows that OpenGL Renderer is set to llvmpipe, which is software rendering. See the low FPS and Mpixels/s rate:
- If you set the restriction to vglusers group, your user should be part of the vglusers group. If you just joined the group, logout and login back so the system will accept the changes.
- The lack of vgl_xauth_key is the most important error. There is a command responsible for the creation of this file when the login manager starts (vglgenkey). And I thought that manually running this program would fix it, BUT NO, IT WON’T! hahahah. I ran vglgenkey manually and it created a file, but the file was different from the one that is created when everything is fine… Here’s me running the command manually…
…vs the file generated correctly by LightDM starting vglgenkey:
See that as soon as init 5 starts LightDM (Graphical Mode), it is going to generate the file for you. My most common causes for this problem were:
-
Configured VirtualGL while using SDDM (fix by installing LightDM, removing SDDM and unconfiguring and reconfiguring vglserver_config again while in console terminal with graphical mode disabled (see next))
-
Configure VirtualGL while graphical mode was running (not even a reboot would fix it… to fix, go to a console terminal (TTY1 for example with CTRL+ALT+F1), stop the graphical mode with “init 3”, re-run vglserver_config to “Unconfigure” and then re-run vglserver_config to configure it again. Now “init 5” or “reboot” to get LightDM to generate the key correctly
-
vglrun glxspheres does not show error, neither shows the spheres:
This happened to me because the ThinLinc Server was physically displaying a console terminal instead of the graphical login screen! The ThinLinc Server was a machine on my left side, so, I just hit “CTRL+ALT+F7” on its keyboard to get it back to graphical mode and the spheres started showing on my ThinLinc client!
If the server machine returns to the console terminal, glxspheres will keep showing, but you will have it hang up again when you try to close it. As I said before, I’m not sure whether you can configure the ThinLinc server with VirtualGL in a way so that you can have local console users and remote virtualgl users through ThinLinc… There’s a “headless nVidia How-To” at VirtualGL homepage that may hold the answer or a change in the vglserver_config options, but I never tried it.
- No sound on local machine or remote machine: ThinLinc sets pulseaudio to forward the sound from the remote to the client machine. However I’ve experienced that a local login concurrently with a remote ThinLinc session for the same user could make the sound stop for the local user. To fix that, the local user could kill pulseaudio (pulseaudio -k) and restart it (pulseaudio -D). That happened a lot when I left the computer at the TV and remotely accessed it through ThinLinc using the same username simultaneously. I don’t recommend you to have a local and a remote graphical login to prevent those small bugs.
Extra: VirtualGL configurations for specific applications
Unfortunately, not all applications will run on GPU simply by using vglrun in front of it. And not all applications will work with VirtualGL, because it is meant for OpenGL applications. Vulkan for example is not going to work (at least for now, hehehe).
You can refer to VirtualGL documentation and see if there’s something about the desired application at session 15: User’s Guide for VirtualGL 3.0
How about Steam Games? Is it possible?
Some OpenGL games will work hardware-accelerated on VirtualGL and ThinLinc, but you have to set the “LAUNCH OPTIONS” for that game. You’re going to get some frameskips because of the way ThinLinc sends the images, but there is a workaround. I’ve made a Reddit post that teaches and demonstrates how to do it in detail - https://www.reddit.com/r/homelab/comments/qkrhv6/i_shared_the_better_computer_at_home_with_my/ - and a video - ThinLinc+VirtualGL+Steam Link: Headless Remote Desktop Gaming Linux Machine - YouTube