1. The Wayland transition
If you’ve followed the Linux desktop world in recent years, you’ve probably heard about Wayland. It’s the modern display protocol designed to replace the decades-old X11 system.
Development of Wayland started around 2008–2010, and by 2015 it began gaining real traction in mainstream distributions such as Fedora and GNOME. Today, it’s the default in many major Linux distributions, including Fedora, Ubuntu, and RHEL.
The transition is ongoing: X11 has been the backbone of Linux desktops for over 30 years, and while Wayland promises a simpler, more secure, and modern architecture, the ecosystem is still maturing. To ease this transition, most distributions provide XWayland, a compatibility layer that allows traditional X11 applications to keep running while the ecosystem catches up.
2. Why this matters for remote desktops
For ThinLinc, display protocols are not just cosmetic. They define how sessions, applications, and graphics get delivered remotely.
With X11, remote desktops could tap into a design that was built from the start with network transparency in mind. Wayland, however, was designed differently: it prioritizes local security and simplicity rather than remote use cases. That means the logic and assumptions that applied for remote desktops on X11 do not directly carry over to Wayland.
A good analogy is the shift in storage from magnetic tape to hard drives. Both served the same purpose—storing data—but the way you accessed and interacted with them was completely different. Tools made for sequential tape access didn’t automatically work on random-access disks. Similarly, while both X11 and Wayland draw pixels, the underlying logic of how you interact with the system is fundamentally different.
As a result, adapting isn’t just about changing code—it’s about rethinking how remote access fits into Wayland’s architecture. And the transition is complex:
-
Distributions adopt Wayland at different speeds.
-
Some applications are Wayland-native, others remain X-only.
-
The broader ecosystem (toolkits, compositors, drivers) evolves unevenly.
This makes the Wayland transition especially important to watch for anyone running or integrating remote desktops.
Fundamentally, Wayland is not compatible with remote desktops in its core design. Compositors and remote desktop applications have to use additional means to work. One possible approach is creating or adopting an extension to the core Wayland protocol that adds some of the missing functionality.
While there are means of using remote desktop applications on Wayland today, the functionality is not part of the Wayland core that all compositors have in common. Different Wayland compositors might adopt additional functionality at different speeds, or sometimes not adopt at all.
This means that a remote desktop application on Wayland might work on some compositors but not on others. In fact, it will never be possible to write a remote desktop application for Wayland that will work on all Wayland compositors. This is in stark contrast to applications written for X11, which has a much broader core that can be usable for remote desktop applications. A benefit of using an X11-based solution like ThinLinc is that it will work with any X11 desktop environment.
3. ThinLinc today on Wayland
There’s sometimes confusion about ThinLinc and Wayland. Some assume that ThinLinc won’t run at all if a distribution has switched to Wayland by default. In reality, ThinLinc can still be used—but it currently requires an X11 desktop environment for the remote session.
In practice, this means that even if your distribution boots locally into Wayland, ThinLinc will start an X11-based session for remote use. This is because ThinLinc comes with an X11 server when it is installed. All you need to do is ensure that an X11-compatible desktop environment is available on your system. How this is set up depends on your distribution.
For example, we’ve documented a specific workaround for running GNOME on RHEL, AlmaLinux, and Rocky Linux 10 in our community forum.
So the key message is: ThinLinc remains usable on Wayland-first systems, provided an X11 session is available.
4. Our work and experiments with Wayland
We have recently taken the first steps in exploring how remote desktops fit within the Wayland landscape. This includes work done in TigerVNC, a core open-source component used in ThinLinc that Cendio maintains and heavily contributes to. TigerVNC is tightly coupled to a desktop and is responsible for transmitting images and managing mouse and keyboard input. Early prototyping is being done in TigerVNC to make it possible to access a local Wayland session remotely.
As part of these experiments, we analyzed the current state of remote desktops in Wayland. We’ve looked at what’s available and used today by other remote desktop solutions, and what limitations there are today. We have begun development on a TigerVNC prototype server that is capable of using both XDG Desktop Portal and Wayland protocol extensions available in wlroots-based compositors. For curious readers, here are some relevant GitHub pull requests with code details and discussions:
* https://github.com/TigerVNC/tigervnc/pull/1947
* https://github.com/TigerVNC/tigervnc/pull/1986
This work is less about rushing to a solution and more about engaging in the conversation and identifying where the gaps are. As it currently stands, a remote desktop session under Wayland will lack certain functionality that would be available under X11. This could be due to a lack of APIs enabling a certain feature, or due to bugs in the compositor. For example, we have seen issues with local cursor rendering working properly, a feature that greatly improves the responsiveness of a remote desktop session.
5. Next steps
Wayland is the future—but it’s a future that needs careful planning.
Our ongoing work focuses on exploring the technologies that are used and available right now. There is still a long way to go before it is possible to achieve the same functionality in a Wayland remote desktop as X11 has today.
This is an active area of exploration for us. We’re investing in experiments, following the community closely, and preparing both TigerVNC and ThinLinc to adapt as the Wayland ecosystem matures. We also communicate with relevant projects, through issues and discussions, to lead the way toward long-term change.
6. Join the conversation
We want to hear from you.
How does Wayland adoption impact your ThinLinc and TigerVNC usage? Are there scenarios where native Wayland support would be a game-changer for you?
Join the discussion in our Wayland category on the ThinLinc Community. Your feedback will help guide where we focus our future development.
7. Closing thoughts
ThinLinc remains reliable and fully usable today, even as the Linux desktop world transitions from X11 to Wayland.
At the same time, we’re actively exploring, prototyping, and collaborating to prepare for what comes next.
This is just the beginning of the conversation, and we’ll continue to share updates and progress. Together with our community, we’ll shape how ThinLinc fits into the Wayland future.
This article was written in collaboration with @samuel, @jeanz, and @adaha.
But as you can imaging, I got a problem. Gnome RDP is limited to the first monitor, very frustrating. I came along this ThinLinc and wonder if that has a production / lab (mission critical) ready solution? I was experimention, but all I managed was it to crash/terminate my current Wayland/Gnome session