The next release of ThinLinc is almost ready. Before the official launch of version 4.21.0, we’re making a beta build available for public testing. This beta includes over 100 fixes and improvements. Some of the most prominent changes are:
ThinLinc Web Access now supports the OpenID Connect authentication
protocol. This enables organizations to delegate authentication to
solutions like Keycloak or Microsoft Entra ID, allowing convenient
single sign-on, and more flexibility in authentication methods and
policy.
ThinLinc session logs are now in the system journal instead of in
xinit.log in the ThinLinc session directories. This avoids multiple
log locations for modern Linux systems, and gives more flexibility
when analyzing logs.
It is now possible to configure the ThinLinc client with mandatory
settings on managed endpoint devices. These settings will be forced
and cannot be overridden by the user.
The Linux ThinLinc client now supports 64-bit ARM (ARM64),
replacing the previous 32-bit ARM client. This improves
compatibility with modern ARM hardware and operating systems.
The platform requirements for the ThinLinc client on macOS have
been raised. It now requires macOS Ventura (version 13) or newer.
Users on older versions of macOS will need to upgrade their
operating system to use this version of the ThinLinc client.
Is there any update on when we will get accelerated 3D support directly from TigerVNC rather than going through VirtualGL? It has been nearly two years now since it was suggested that this would be an upcoming feature. This would be the biggest quality of life improvement for our users by quite some margin.
The feature is actually there in upstream TigerVNC, but the main issue is that it doesn’t work with the proprietary NVIDIA drivers, for reasons which are somewhat beyond our control. Given NVIDIA’s market share, we figured that this would be too much of a “caveat” to warrant including the feature in ThinLinc at this stage. Hope that clarifies things.
Last time I looked, this was due to a lack of support in the NVIDIA drivers for DRI3. That is no longer the case, so er, what is the holdup? The TL;DR is that Wayland basically forced NVIDIA’s hand.
These discuss the lack of DRI3 in the proprietary NVIDIA driver and are from posts well over a year old. As I said DRI3 v1.2 is now INCLUDED in the proprietary NVIDIA driver. I posted a link for you to know I was not making things up. It would appear Cendio is working with out of date information and consequently unnecessarily holding back the transparently accelerated OpenGL feature.
How about the support for the latest Ubuntu variant, is there any chanse it is coming back or should I consider finding the distribution that is second best for being beginner-friendly Linux and supports Thinlinc?
ThinLinc should work fine on Ubuntu 26.04, however the default desktop environment on this distribution (GNOME 50) has removed support for X11, which ThinLinc requires. We currently have a plan to support Wayland instead (see here), which will allow GNOME 50+ to be used in a ThinLinc session again. However, we generally recommend using other more lightweight desktop environments anyway such as MATE or XFCE, since these tend to give a better end-user experience in a remote desktop session. So if you haven’t already, please give these a try on Ubuntu 26.04 and see what you think; ThinLinc ships with predefined profiles for these desktop environments, so it should be sufficient to install them from the Ubuntu repositories without any additional configuration. Hope that helps!
These discuss the lack of DRI3 in the proprietary NVIDIA driver and are from posts well over a year old. As I said DRI3 v1.2 is now INCLUDED in the proprietary NVIDIA driver. I posted a link for you to know I was not making things up.
Thanks for the link, and no, we didn’t think you were making it up. We’re aware DRI3 v1.2 is in the driver now. The problem is that DRI3 being present isn’t the same thing as the feature working. NVIDIA’s DRI implementation is missing parts that specifically complicate TigerVNC’s use of it. This is not the case in other driver implementations. They have it on paper, but the support isn’t good enough in its current state for us to ship this as a supported feature with our stamp of approval on it.
Worth noting that the upstream issue @aaron linked is still open, so this isn’t resolved upstream either.
It would appear Cendio is working with out of date information and consequently unnecessarily holding back the transparently accelerated OpenGL feature.
The driver is only one of the two blockers, and it’s not the bigger one. TigerVNC’s implementation is lacking in terms of optimization and performs significantly worse than VirtualGL in many scenarios. Getting it to a production-ready state is a significant amount of work, not a switch we refuse to flip.
So the trade-off as we see it: VirtualGL is a proven solution that people run in production today, and TigerVNC’s DRI3 GPU acceleration isn’t (yet).
None of which means it’s shelved. We want to get there, and when it’s the better option, we’ll ship it. If you have specific workloads where VirtualGL is causing you problems, that’s very useful for us to hear, since it helps us define what “good enough” really entails.
