Hardware Accelerated Graphics on Remote Desktop Session using ThinLinc and VirtualGL - A guide

Hi guys

Let’s TLDR for you: This Guide is meant to help you install and configure ThinLinc Server and VirtualGL on the same host machine, so that you can have a secure multi-user full remote desktop session experience with sound and hardware accelerated graphics for OpenGL applications. I had some struggles trying to configure both, so I decided to document it and share with you.

Intro and motivation:
At the start of pandemics lockdown, I had to find a way to share the “better computer” with both my nephew and wife. I was working home-office as sysadmin, my nephew was taking classes remotely and my wife was also working/studying. We had 3 machines: my 4th gen i5 notebook running openSUSE Leap (with SSD, 8GB Ram and a GTX 850M), a slow Centrino notebook and a Raspberry Pi 2. VNC was not enough because it had no sound (I think that it has workarounds, but never tried) and wifi signal some times was weak enough to give us responsiveness problems and poor graphic quality. So, I’ve found ThinLinc, that is a Remote Desktop solution for Linux based on FOSS. It is not FOSS itself, but it is built on top of TigerVNC and noVNC by a company named Cendio (maintainers of both TigerVNC and noVNC). ThinLinc had the improvements needed for me and my family because we could share one computer for our daily activities and no one had to have a bad experience using one of the slower machines (such as the Raspberry Pi 2 as a desktop). ThinLinc is free for up to 5 simultaneously connected users, so it also saved me some money. If you need more users connected at same time, their pricing is very competitive and you get support included. Check at cendio.com

It was very simple to install ThinLinc Server on Leap. And then after some lockdown time we were allowed to phisically access our office one person at a time. And I had an openSUSE Tumbleweed machine there that was shut down and could also be used for my home office days by using ThinLinc. And then some struggles came and it took me some time to figure out what was different that prevented ThinLinc Server to be installed on the Tumbleweed machine. It was easy but undocumented, that’s the first motivation for this guide.

Second motivation is: One day my nephew at home tried to start some game remotely and it simply didn’t open. Another game had a sluggish FPS that he couldn’t play it. Some other video editing software refused to open because it claimed that it couldn’t run without the GPU… Well, Steam Link could be enough for us, but I was working and Steam would just stream the local screen to Steam Link and you are not able to use the computer locally.
And that’s when I learned about VirtualGL, a FOSS application that let the machine process hardware accelerated graphics on the host GPU and forward it to another machine… And it could be installed along ThinLinc Server and be configured to work together, so a ThinLinc client can benefit from hardware accelerated graphics for OpenGL applications: A remote desktop session with sound and GPU accelerated graphics sounds fantastic, but I’ll documment some tricks that I learned from try and miss trying to get both working. In the end, the answer for my problems were simple. About VirtualGL, it is in openSUSE OSS repo and also can be downloaded at virtualgl.org (the most recent version is not on OSS repo yet).

Third motivation is: I got a new machine at work and was in doubt if I should reinstall Tumbleweed from scratch or just clone my SSD and continue with the same installation that I have for several years. I had to test if my Remote Access solution would work (and know if I still could remember all the steps that I did in the past.

To make this guide, I based on the lovely openSUSE Tumbleweed KDE. I’m used to LXDE though, but KDE had some extra configuration steps that I didn’t know.

CONTINUE

ThinLinc + VirtualGL on fresh openSUSE Tumbleweed: proper way to install

As I said, I got a new machine and decided to fresh install openSUSE Tumbleweed and set it up to use ThinLinc and VirtualGL for remote access. Despite being a long time openSUSE user and already having some experience on using ThinLinc and VirtualGL before, I had some struggles that I wasn’t expecting. So, I decided to document the problems encountered and what I had to do to fix them, because I was hoping it would work right out of the box and it was more tricky than I expected.

**OpenSUSE Tumbleweed installation:
**I got the NET Installer (on January 12th 2022) because Tumbleweed is a rolling release distro and I think that it makes no sense to download a full DVD installer if the packages will get old very fast… This way, the fresh installed system would be updated to the last packages out of the box.
Installed the system in Brazilian Portuguese (guess where I’m from) and chose the US International keyboard map because that’s the keyboard layout that I’m going to use.
I’m used to LXDE, but for this fresh install I decided to go with KDE Plasma to check how it would perform on the new machine… and that’s great because one of the struggles I think may be related to missing some GTK packages and default login manager SDDM.
Formatted the SSD to EFI partition plus swap and BTRFS root.
Enabled SSH and opened the SSH port on the installer last step (because ThinLinc is going to use it).

**Out-of-box struggles
**After the installation, I expected that installing ThinLinc and VirtualGL would be as simple as downloading and installing the ThinLinc server and installing VirtualGL from the openSUSE official repo. But then I found some problems that took me some time to fix. Here is a step by step installation with some advice on what to do and what not. Here we go:
Starting with ThinLinc installation because it’s the main program of our tutorial. It’s going to let us use our computer remotely as if we were sitting in front of it. On openSUSE Tumbleweed there’s some things to pay attention to.

(CONTINUE)

**ThinLinc Server installation from command line - CLI
**

  • Download and unzip ThinLinc Server Installer. At Cendio’s ThinLinc Download page, is the button “Download ThinLinc Server bundle” under the “For Administrators - ThinLinc Server (Linux only)”. It comes as a zip file. Unzip it and there are two installers: one GUI and one CLI:

pic01

  • For the CLI installer, run the install-server script as root or with sudo. If you want the GUI installer, open a file browser and double-click the “Click to Install.desktop”. The GUI installer will have the same options listed here and the pictures are provided in the next chapter.

pic02

  • It will install the ThinLinc packages (rpm version because it detected that I’m running openSUSE):

pic03
pic04

  • After the screen above, it’s going to propose you to run the tl-setup and configure ThinLinc, but to save you some time say NO and run it afterwards because it won’t be able to successfully configure it and start the needed services. Why? Because the openSUSE team decided to move some parts of the system to the /usr/ folder on Tumbleweed. If you’re using Leap, I guess that it should be ok for you to just continue because Leap 15.3 still didn’t move parts of the system to under /usr/. Here’s the question and if you’re on Tumbleweed, say NO and let fix it first on the next step:

pic05

  • Here’s what you need to fix on Tumbleweed (and maybe Leap 16 or some Leap versions after 15.3): At some point, openSUSE devs decided that part of the system should be moved under /usr/ folder. In our case, the file /etc/pam.d/sshd was moved to /usr/etc/pam.d/sshd and ThinLinc’s tl-setup is searching for it in the wrong place. To workaround, create a “symlink” that points to the right file in the place where tl-setup thinks it is located by running “ln -s /usr/etc/pam.d/sshd /etc/pam.d/sshd”. Here’s what I did:

pic06

  • Now that the symlink exists, running tl-setup won’t give you any trouble. Run tl-setup as root (should be in your PATH, but you may also use the full path: /opt/thinlnc/sbin/tl-setup). There are few steps and it’s very quick to get it working, here you go: tl-setup as root on opensuse will open the text mode. If you want the GUI, maybe “xdg-su -c tl-setup” as a normal user will bring you the GUI version with the same options. Let’s use the CLI tl-setup for now:

pic07

  • Accept the License Agreement

pic08

  • For a simple installation, when you want to have a single machine being accessed remotely, install the Master and that’s it. Both the Master AND Agent roles will be running on the same machine. If you have more than one machine and want to build a distributed remote access cluster with more features such as load balance and other things, then you should have one Master and multiple agents that will work together with the master. In our case, This is the only machine, so, I’m choosing Master (and it will also have an Agent running, I’ll explain later when talking about machines under NAT). Default is Master

pic09

  • Ok, so, here’s a catch: The CLI and GUI for installers and tl-setup should work the same, with same options and steps, but turns out that for openSUSE Tumbleweed KDE (and other non GTK based Window Managers maybe), there are some missing GTK+ dependency. The GUI installer and GUI tl-setup are going to warn you and ask you if it should install those dependencies for you, along with the command line that is going to be run. BUT the CLI installer and CLI tl-setup will just warn you about GTK+Dependency. I’ve tested without installing those dependencies and the only thing that I missed was the welcome screen when the client connects to the remote machine, but I’m not sure if there are other problems. To save you some time, for openSUSE Tumbleweed, the GTK+ dependencies that you have to install are: typelib-1_0-Gtk-3_0 and python3-gobject-Gdk and you may install both by running “sudo zypper install typelib-1_0-Gtk-3_0 python3-gobject-Gdk” on another terminal or after finishing tl-setup. The above package names will appear on the GUI version of tl-setup and it will ask you if it should install it for you. I’ll provide the GUI image later. Run “sudo zypper install typelib-1_0-Gtk-3_0 python3-gobject-Gdk” inside another terminal or after finishing tl-setup.

pic10

  • The dependencies may vary from distro to distro… on openSUSE Tumbleweed you should get this another dependency warning… but this time, tl-setup will offer to install it for you. Accept it please.

pic11
pic12
pic13

  • Fill in your e-mail for administrative messages. I’m not sure if this works for the ThinLinc Server to send messages or if Cendio is collecting your e-mail for the case if you’re buying a ThinLinc license. As a free user, they never sent me an e-mail or SPAM. ThinLinc is free for up to 5 simultaneously connected users per domain.

pic14

  • ThinLinc has a web administration tool that provides you with some reports and configurations. It’ll run on port 1010 on your Master. You can set a password for the “admin” user or skip it.

pic15

  • With ThinLinc, a client may print to their local printers from the remote machine and it also can detect the correct printer based on your location. I’ve never tested this feature, but it will add two printer queues that will show when you try to print (locally or remotely).

pic16
pic17

  • If you’re using a supported firewall, it will offer to open ThinLinc needed ports: Accept it or check if the ports are open on your firewall.

pic18
pic19

  • It will also offer to configure your AppArmor if you’re using it

pic20
pic21

  • And now you should see this message saying that you’ve finished setup…

pic22

  • … and it is going to start the services and confirm that it’s up and running

pic23

  • If instead of the picture above you get an error message like this one below, check the tl-setup log to figure out what was the problem:

pic24

The log is located at “/var/log/tlsetup.log”.
pic25

For example: If you didn’t create the symlink for pam.d/sshd on step 5, your log will have a message like this one below:
pic26

For this error example above, to fix it, create the symlink for /etc/pam.d/sshd as described in step 5 and run tl-setup again. The reason for the failure is because ThinLinc is going to create a /etc/pam.d/thinlinc symlinking it to /etc/pam.d/sshd, which was moved to /usr/etc/pam.d/sshd on openSUSE Tumbleweed. Other distros may not have this problem. Here’s the log file for tl-setup if the sshd symlink was made (or if the distro didn’t move it elsewhere) and everything was ok:
pic27

**ThinLinc Server installation from graphical user interface - GUI
**

  • If instead of using the “install-server” CLI script you double-click the “Click to Install.desktop” file (that was extracted from the zip file at Cendio’s ThinLinc Download page, is the button “Download ThinLinc Server bundle” under the “For Administrators - ThinLinc Server (Linux only)”.

pic28

  • On openSUSE Tumbleweed KDE (and maybe some distros/window manager combinations), the installer will complain about missing GTK+ Dependencies just like in CLI’s step 6, except that it will provide you the package names, the full zypper command to install them and also will offer to install it for you!

pic29
pic30
pic31

The only mistake is that after opening this terminal and installing the needed dependencies, It will ask you to restart install-server. Instead of install-server, double-click “Click to Install.desktop” again…
pic32
pic33

And now it should suggest that you continue as root…
pic34

  • The following screens are going to have a corresponding CLI screen. Please go up and refer to the CLI installation guide: The screen below for example is equal to CLI’s installer step 2:

pic35

And then the following screens will be the same as CLI’s step 3, 4, but in GUI.
Please, pay attention to CLI’s installer step 5, as it is not done under ThinLinc installer, but at a Linux terminal. If your distro doesn’t have file /etc/pam.d/sshd, step 5 is about creating the symlink pointing to where your distro keeps sshd. As we are talking based on openSUSE Tumbleweed, it’s now located at /usr/etc/pam.d/sshd. ThinLinc needs /etc/pam.d/sshd because it’s going to create /etc/pam.d/thinlinc pointing to sshd. If your distro puts it elsewhere, it will result in an error.

  • Continue the steps reading the info from the CLI guide as it should be the same. After finishing, You should have a working ThinLinc Server on your machine.

CONTINUE

**What happens if I don’t install the dependencies?
**I’m not sure which dependencies are really needed and for what, but for example, if you don’t install the GTK+ dependencies, clients connecting to your ThinLinc Server won’t get the “ThinLinc Welcome Screen”. The Welcome Screen for example is where the user may choose the session’s desktop environment if more than one is provided. Please install the dependencies to avoid conflicts.

**ThinLinc Server on other distros and desktop environments:
**Both CLI and GUI installers should work with more or less the same steps. I’ve installed on openSUSE Leap 15.3 LXDE and Linux Mint 20.3 Cinnamon and the differences were minimal. Leap 15.3 for example still has sshd located at /etc/pam.d/sshd, so the symlink is not needed. Maybe in the future it moves it elsewhere, but for now, this CLI tutorial’s step 5 is not needed (it’s not going to let you replace the file for a symlink, don’t insist or try to remove the file before!). Also, I don’t remember that there were GTK+ dependencies, maybe because I’m using LXDE.
Mint 20.3 installed .deb packages instead of .rpm ones (because those are the kind of packages that it uses) and had other dependencies, but not GTK+. Also, the sshd symlink was not needed. I still didn’t try to install ThinLinc on a distro that uses another kind of package (i.e. not RPM or DEB).

**How about the ThinLinc Client? How do I access my ThinLinc Server?
**It’s not the main focus of this document, but Cendio provides you with ThinLinc Clients for WIndows, Mac and Linux machines at their download page, for different system architectures and package types. By default, your ThinLinc Server is also going to have a browser client running on it that you can reach at port 300 from any HTML5 capable browser without installing anything to your client, just open a web browser and try https://ThinLincServer’sIP:300 .
The installed clients however have more options. Just install, open and try to connect to your ThinLinc Master Server’s IP. If you’re on the same network or your Master has a public IP Address, it’s very simple. If you’re under NAT, please, read these links:
https://www.reddit.com/r/homelab/comments/qkrhv6/i_shared_the_better_computer_at_home_with_my/https://community.thinlinc.com/t/my-personal-thinlinc-use-case-and-some-performance-comparison/173
Both have my workaround using SSH Tunneling to reach a ThinLinc server under NAT and configuring the HOST_ALIASES parameter for the client. The reddit link also has a reference video that covers it in detail. You may also check Cendio’s official guide for servers under NAT: https://www.cendio.com/resources/docs/tag/network.html#network_nat .

(CONTINUE)

**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 meant for openSUSE Tumbleweed KDE installation 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! 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.

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.

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)

pic01

  • 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: https://virtualgl.org/Documentation/OSSupport - 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:
    pic02

  • Remove sddm with “zypper remove sddm” as root (or if you were using another login manager, replace sddm with the one you were using):

pic03
(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: https://rawcdn.githack.com/VirtualGL/virtualgl/3.0/doc/index.html#hd006001 . 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.

pic04

  • And now, run vglserver_config as root:

pic05

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 - https://rawcdn.githack.com/VirtualGL/virtualgl/3.0/doc/index.html#hd006001

  • 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.

pic06

edit the desired user
pic07

on Details tab, select vglusers and click OK
pic08
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:
pic09
pic10

You can verify if the user is in a group by using groups command:
pic11

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!

(CONTINUE)

**Testing if everything is working fine
**The easiest way to test is to go to another computer on the same network, install ThinLinc client 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.

  • Open your ThinLinc Client in another computer and input the server address, username and password:

pic12

  • You should see the ThinLinc’s welcome screen:

pic13
pic14
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:

pic15
I don’t know if there are some other problems, but if you want to fix it, refer to the ThinLinc Server installation on this guide.

  • You now are remotely connected to your ThinLinc Server

pic16

  • To check if VirtualGL is working, open a terminal and run “vglrun glxspheres” (it should’ve been installed along with VirtualGL).

pic17
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.

pic18
pic19

  • vglrun glxspheres seems to hang and no error or spheres are shown:

pic20

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)
pic21

  • vglrun could not open display

pic22

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.

pic23

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:
pic24

  • 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…

pic25

…vs the file generated correctly by LightDM starting vglgenkey:
pic26

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:

pic27

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!
pic28

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.

(CONTINUE)

**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: https://rawcdn.githack.com/VirtualGL/virtualgl/3.0/doc/index.html#hd0015

**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 - https://youtu.be/aiLB0-Jbwlw

**Why combine all this ThinLinc + VirtualGL + Steam Link stuff for some games if I could simply use Steam Link alone for every game or the ThinLinc+VirtualGL for the same OpenGL games?
**I tried to answer this one in the video linked above, but in case that you missed it or is not clear, ThinLinc uses TCP packages for sending the image from the host to the client. While this ensures a better image quality because that TCP ensures that the full screen is rendered everytime, because of bandwidth and latency, high FPS applications such as games won’t be able to draw every frame, starting some “frame skip”. Please note that frame skip does not necessarily mean low FPS rate: during frame skips, the game runs full speed, but frames won´t have enough time to draw and confirm due to TCP. Most games and some demanding graphical applications without hardware accelerated graphics from GPU using VirtualGL will be slow because it will be rendered on software (and will also have frame skips).
Steam Link alone streams the screen from the session that the game is running… If you open Steam on your computer and connect a Steam Link to it, your computer’s screen is going to be streamed to Steam Link. Anyone in front of the PC will see and can interact at the same time. There are some tutorials for “Headless Steam Server” that I’ve seen, but I never tested it. So, if you want some privacy or want to share the computer so that someone else can be connected to it locally or not, you need ThinLinc’s ability for virtual sessions. You can even connect remotely, start Steam on the remote desktop session and leave it running in the background (i.e. close the window!).
Lastly, what is Steam Link used for? Well, Steam Link streams the screen using other protocols not based on TCP. That means that it can send images quicker, reducing frameskips and if there’s any problem with part of the packages, only part of the screen will briefly show some artifacts just like an old cassete being played on the VCR. Also, Steam Link has a better controller responsiveness (for controllers and keyboard/mouse). You can’t play FPS games for example using only ThinLinc+VirtualGL because of the way the mouse input is passed to the remote machine (I GUESS). And can’t use controllers also if not through Steam Link.

**That’s It!
**Thanks Cendio and VirtualGL for the excellent software that help me a lot, so I can have a nice remote desktop experience even behind a slow connection with GPU accelerated graphics. Thanks openSUSE Brazilian Telegram guys for pointing me out some differences between Tumbleweed and Leap and thank you for reading.

PS: (I promise that I’m going to review if the pictures are correct and formatting tomorrow!)

**Images Uploaded HERE ThinLinc Server Install Guide - Album on Imgur
**

Pictures at: VirtualGL Install Guide - Album on Imgur

Pics uploaded here Testing if ThinLinc+VirtualGL are working fine - Album on Imgur