# ThinLinc 4.21.0 beta
**URL:** https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030
**Category:** Blog
**Tags:** release, beta, thinlinc
**Created:** [30 June 2026 08:09 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030 "2026-06-30T08:09:01Z")
**Posts on this page:** 17
**Page:** 1
### Author:  [@linn](https://community.thinlinc.com/u/linn)
#### Post date: [30 June 2026 08:09 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/1 "2026-06-30T08:09:02Z")
# ThinLinc 4.21.0 beta available for testing
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.
You can find the download links and full release notes here: [ThinLinc Beta Release | ThinLinc by Cendio](https://www.cendio.com/thinlinc/download/beta)
As always, please keep in mind that this is a pre-release version and not recommended for critical production environments.
Let us know what you think in the comments below. If you run into any hiccups or unexpected behavior, please report it!
---
### Author:  [@wilsj](https://community.thinlinc.com/u/wilsj)
#### Post date: [30 June 2026 08:17 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/2 "2026-06-30T08:17:14Z")
The development team has really outdone themselves on this one. I highly recommend giving the full release notes a read, it’s packed with highly requested tweaks and features: [https://www.cendio.com/downloads/beta/release-notes-4.21.0.txt](https://www.cendio.com/downloads/beta/release-notes-4.21.0.txt)
---
### Author:  [@jabuzzard](https://community.thinlinc.com/u/jabuzzard)
#### Post date: [18 July 2026 09:49 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/3 "2026-07-18T09:49:26Z")
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.
---
### Author:  [@aaron](https://community.thinlinc.com/u/aaron)
#### Post date: [20 July 2026 18:24 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/4 "2026-07-20T18:24:58Z")
It’s 90% there, just the other 90% left to go 😉
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.
---
### Author:  [@jabuzzard](https://community.thinlinc.com/u/jabuzzard)
#### Post date: [20 July 2026 18:45 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/5 "2026-07-20T18:45:24Z")
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.
> **[NVIDIA R595 Linux Driver Beta Brings New Vulkan Support & DRI3 v1.2](https://www.phoronix.com/news/NVIDIA-595.45.04-Linux-Beta)**
>
> Following the recent NVIDIA R595 driver release for Windows, NVIDIA today released the 595.45.04 driver for Linux users as a beta version in the R595 release stream.
---
### Author:  [@aaron](https://community.thinlinc.com/u/aaron)
#### Post date: [20 July 2026 19:45 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/6 "2026-07-20T19:45:48Z")
I’m a bit short on details, but here’s the upstream issue:
>
>
> \*\*Describe the bug\*\*
> If I run an OpenGL application with an Nvidia card for acce…leration, then the application will still be unaccelerated. This can also be seen using \`glxinfo\` which shows \`llvmpipe\`
>
> \*\*To Reproduce\*\*
> Steps to reproduce the behavior:
> 1. Run \`glxinfo\`
> 2. See \`OpenGL renderer string: llvmpipe (LLVM 18.1.6, 256 bits)\`
>
> \*\*Expected behavior\*\*
> See \`OpenGL renderer string: NVIDIA GeForce RTX 4060/PCIe/SSE2\`.
>
> \*\*Client (please complete the following information):\*\*
> No client needed.
>
> \*\*Server (please complete the following information):\*\*
> - OS: Fedora 40
> - VNC server: TigerVNC
> - VNC server version: 1.14.0 beta
> - Server downloaded from: Built using contrib spec file
> - Server was started using: \`Xvnc :2\`
>
> \*\*Additional context\*\*
> The issue seems to be that it still tries the mesa drivers. I get this error during startup of the application:
>
> \`\`\`
> glx: failed to create dri3 screen
> failed to load driver: nouveau
> DRM kernel driver 'nvidia-drm' in use. NVK requires nouveau.
> glx: failed to create dri3 screen
> failed to load driver: nouveau
> \`\`\`
>
> ~If I force glvnd to pick the Nvidia driver, then everything works:~
>
> \`\`\`console
> $ \_\_GLX\_VENDOR\_LIBRARY\_NAME=nvidia DISPLAY=:2 glxinfo | grep renderer
> OpenGL renderer string: NVIDIA GeForce RTX 4060/PCIe/SSE2
> \`\`\`
>
> ~No such issue appears for Vulkan. I guess there is a better mechanism there.~
>
> \*\*Edit:\*\* The initial testing was not correct. The NVIDIA driver is not using DRI3 with proper acceleration, even with that environment variable.
---
### Author:  [@jabuzzard](https://community.thinlinc.com/u/jabuzzard)
#### Post date: [20 July 2026 20:13 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/7 "2026-07-20T20:13:19Z")
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.
---
### Author:  [@ThePRG](https://community.thinlinc.com/u/ThePRG)
#### Post date: [28 July 2026 13:04 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/8 "2026-07-28T13:04:34Z")
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?
---
### Author:  [@aaron](https://community.thinlinc.com/u/aaron)
#### Post date: [29 July 2026 05:06 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/9 "2026-07-29T05:06:20Z")
Hi,
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)](https://community.thinlinc.com/t/wayland-tigervnc-and-thinlinc-the-future-of-remote-desktops-in-linux/1755), 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!
---
### Author:  [@Harj](https://community.thinlinc.com/u/Harj)
#### Post date: [4 August 2026 20:49 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/10 "2026-08-04T20:49:15Z")
Updated the lab to 4.21.beta although I’ve not fully tested that nothings broken since the update.
---
### Author:  [@ThePRG](https://community.thinlinc.com/u/ThePRG)
#### Post date: [11 August 2026 07:58 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/11 "2026-08-11T07:58:08Z")
Ubuntu 26.04 does not really ship with the MATE flavour anymore, but I installed all the needed packages and it seem to work ok. Thanks!
---
### Author:  [@wilsj](https://community.thinlinc.com/u/wilsj)
#### Post date: [11 August 2026 14:41 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/12 "2026-08-11T14:41:58Z")
> 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.
---
### Author:  [@Harj](https://community.thinlinc.com/u/Harj)
#### Post date: [13 August 2026 15:53 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/13 "2026-08-13T15:53:09Z")
Chiming in. With our own testing may be relevant here, particularly around NVIDIA GPUs.
As part the Thinlinc eval, I tested VirtualGL 3.1.4 with an NVIDIA Quadro P4000 (580.x driver) across a number of OpenGL/GPU workloads (AlmaLinux 9.8 + XFCE - 8vCPU, 36GB RAM, SSD local disks) including 4.21 beta.
Interestingly, VirtualGL 3.1.4 isn’t the performance bottleneck. The issue was more inconsistent GPU utilisation from the NVIDIA proprietary driver. With some graphics-intensive workloads the GPU was significantly under-utilised, leaving up to ~70% of potential performance on the table.
This was app dependent rather than universal, e.g. Blender Cycles GPU and Houdini Karma XPU Renderers able to utilise the GPU correctly (90-100%) and delivered the expected performance.
I tried numerous VGL and X11 settings, various 580.x drivers but the results were always consistent with some apps only utilising 30% of the P4000’s potential.
---
### Author:  [@jboettge](https://community.thinlinc.com/u/jboettge)
#### Post date: [14 August 2026 07:10 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/14 "2026-08-14T07:10:40Z")
```markdown
Thank you very much for that feature we all have waited for. While testing the beta i figured out, that there is a misbehavior with the discovery URL which makes OIDC discovery fails with authentik: "Issuer mismatch" due to trailing slash\
ThinLinc 4.21.0 beta 1, Web Access OIDC against authentik.
Login fails immediately with:
ERROR tlwebaccess\[1796343\]: Failed to generate IdP redirect: 'Failed to fetch OIDC
discovery document from ''https://auth.example.com/application/o/thinlinc/.well-known/openid-configuration'':
DiscoveryError("Issuer mismatch: got ''https://auth.example.com/application/o/thinlinc/'',
expected ''https://auth.example.com/application/o/thinlinc'' (from configured discovery URL)")'
**Cause**
ThinLinc derives the expected issuer by stripping `/.well-known/openid-configuration`
from the configured `discovery_url`, which yields a value without a trailing slash.
authentik advertises its issuer *with* a trailing slash
(`https://auth.example.com/application/o//`) while serving the discovery
document at the slash-less concatenation. The exact string comparison therefore fails.
This does not happen with Keycloak (`https://kc.example.com/realms/`) or
Entra ID (`https://login.microsoftonline.com//v2.0`), since their issuers have
no trailing slash. authentik's issuer format is not configurable — the global issuer
mode ends in a slash as well.
**config**
/webaccess/oidc/providers/authentik/
discovery_url = https://auth.example.com/application/o/thinlinc/.well-known/openid-configuration
client_id = ...
scope = openid email profile
username_claim = preferred_username
**Suggested fix**
Take the issuer from the `issuer` field of the discovery document instead of deriving
it from the URL, and validate it only against the `iss` claim of the ID token (where
exact string comparison is required per spec). Alternatively, add an optional
`issuer` parameter to the provider block so the expected value can be set explicitly.
**Workaround?**
Is there a supported way to override the expected issuer? The only thing I can think
of is configuring `discovery_url` with a double slash
(`.../application/o/thinlinc//.well-known/openid-configuration`) plus a rewrite in the
reverse proxy in front of authentik — which is obviously not something I want in
production.
```
---
### Author:  [@aaron](https://community.thinlinc.com/u/aaron)
#### Post date: [17 August 2026 00:02 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/15 "2026-08-17T00:02:16Z")
@samuel is this something we’re aware of?
---
### Author:  [@samuel](https://community.thinlinc.com/u/samuel)
#### Post date: [17 August 2026 06:39 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/16 "2026-08-17T06:39:22Z")
Authentik was not tested because it wasn’t something we had heard from customers about.
If we had this feedback just a bit earlier in the process we might have had time to include a fix in 4.21.0. It’s too late for that now I’m afraid.
@jboettge could you create a Bugzilla entry for what you found at [bugzilla.cendio.com](http://bugzilla.cendio.com)? If so, we’ll take it from there.
---
### Author:  [@Zeijlon](https://community.thinlinc.com/u/Zeijlon)
#### Post date: [21 August 2026 09:21 UTC](https://community.thinlinc.com/t/thinlinc-4-21-0-beta/2030/17 "2026-08-21T09:21:01Z")
@samuel, @aaron and @jboettge – Our interpretation of the OIDC discovery spec. is that the `issuer` property shouldn’t have a trailing slash if it’s handled according to the spec.
I’m basing this on [4.1](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationRequest) together with [4.3](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationValidation), but it could be that Authentik has interpreted the spec. differently.