Learn Remote Desktop - X11 vs Wayland: Implications for VNC

#Introduction

Almost all the VNC practice in this series runs on X11. But Linux is in the middle of a large-scale transition to Wayland, and this transition shakes the foundation of classic VNC. Episode 17 explains why — and what you should do if your target machine is already running Wayland.

You'll understand the fundamental differences between X11 and Wayland, why x11vnc and TigerVNC Xvnc are limited on Wayland, and meet three bridges to the modern world: the native GNOME Remote Desktop, TigerVNC's w0vncserver in version 1.16, and other compositors like KDE krfb.

#X11 and Wayland: Fundamental Differences

#Who Holds the Screen and Input

In X11, there's a centralized display server that manages windows, input, and the framebuffer. Applications are allowed to request screen snapshots, read input events, and interact with other windows. This is what lets x11vnc or x0vncserver "read" the screen freely.

In Wayland, that role is held by the compositor. The compositor is the only party entitled to display content on the screen and receive input. Applications can't arbitrarily read other applications' windows — every access must go through official protocols and explicit permissions.

X11      ->  centralized display server  ->  free access
Wayland  ->  compositor holds control  ->  access via protocol

#Why Classic VNC Is Limited on Wayland

#The x11vnc and Xvnc Problem

This architectural change becomes a wall for classic VNC:

• x11vnc works by reading an X11 display's framebuffer. On pure Wayland, there's no X11 display to read — x11vnc can't even run natively.
• TigerVNC Xvnc does create its own X11 display virtually, so it can still run on top of Wayland as a separate session (not sharing the active Wayland session). But it can't share the running Wayland screen.
• Accessing an active Wayland session requires compositor support for exporting the framebuffer — something each desktop must build specifically.

The impact is clear: on a Wayland-native machine, old VNC tools can no longer "see" the desktop in use.

#The Wayland Solution: GNOME Remote Desktop

#Native Wayland from GNOME

The first and most mature bridge is GNOME Remote Desktop. Because it runs inside the GNOME compositor (Mutter), it can legitimately access the framebuffer and input according to the Wayland protocols. It natively supports both VNC and RDP.

grdctl status

The grdctl status command shows the status of the GNOME remote desktop service. Full configuration via grdctl will be covered thoroughly in episode 18 — suffice it to say this is the main solution for GNOME Wayland desktops.

#The Wayland Solution: TigerVNC w0vncserver

#TigerVNC 1.16 for Wayland

Starting with TigerVNC 1.16, the community provides w0vncserver — a VNC server designed to share Wayland sessions. Unlike Xvnc, which creates an X11 display, w0vncserver grabs the framebuffer from the Wayland compositor through a portal and serves it as a VNC server.

w0vncserver --help

This support still depends on the ScreenCast feature provided by the compositor. In environments where GNOME Remote Desktop isn't wanted, w0vncserver offers a TigerVNC-based alternative that stays in the tool family you already know.

#The Wayland Solution: Other Compositors

#KDE krfb

KDE provides krfb — a desktop sharing application integrated with the KDE Plasma compositor. Like GNOME Remote Desktop, krfb runs inside the Wayland environment and can share the active session:

sudo apt install krfb

On KDE, krfb appears as part of the Sharing settings. Because it lives inside the compositor, it doesn't face the Wayland wall that hampers classic VNC tools.

#Choosing Based on Your Desktop

A summary of options in the Wayland world:

The message is clear: in the Wayland era, you can no longer "attach" x11vnc to a running desktop. The remote desktop solution must come from the compositor ecosystem itself.

#Checking the Session Type

#Is the Machine Already on Wayland

Before planning your remote strategy, first confirm the session type running on the target machine. These two commands answer it quickly:

echo $XDG_SESSION_TYPE
loginctl show-session $XDG_SESSION_ID -p Type

If the output shows wayland, classic VNC tools can't share the active desktop and the native solution is the right choice. If the output is x11, all the tools from episodes 4-7 still work as usual — x11vnc and x0vncserver can be used directly.

#Matching the Strategy

With the session type known, the decision becomes clear: X11 sessions use the classic tools you've mastered, Wayland sessions use native compositor solutions. Both are valid — the key is not forcing the wrong tool onto the wrong architecture.

#Conclusion

Episode 17 explained the X11 versus Wayland struggle: on X11, screen access is free so x11vnc and Xvnc work; on Wayland, the compositor holds control so classic VNC is limited, and the bridges are GNOME Remote Desktop, TigerVNC 1.16's w0vncserver, and KDE krfb.

Key takeaways:

• Wayland gives the compositor full control over screen and input.
• x11vnc and Xvnc can't share a running Wayland session.
• GNOME Remote Desktop is the native solution for GNOME desktops.
• TigerVNC 1.16's w0vncserver shares Wayland via the ScreenCast protocol.
• KDE uses krfb, integrated with Plasma.
• On Wayland, the solution must come from the compositor ecosystem.

In the next episode, episode 18, we practice directly with GNOME's modern solution: GNOME Remote Desktop — modern setup — enabling RDP and VNC with grdctl, setting passwords, view-only mode, and configuration via GNOME Settings for headless sessions. See you there!