GNOME 50 and the End of X11: What Changes for You

GNOME 50, codenamed Tokyo, finishes a transition that has been underway for years: the desktop no longer supports logging in with an X11 session. The X11 code has been removed from Mutter, the window manager and compositor at the heart of GNOME, and from GNOME Shell. If you use GNOME, whether directly or through a distribution such as Ubuntu 26.04 LTS or Fedora 44, you are now running on Wayland.

For most people this changes nothing visible. For some workflows it changes a lot. This guide explains what actually happened and how to check whether you are affected.

X11 and Wayland in plain terms

A display server decides how windows are drawn, how keyboard and mouse input reach them, and how applications share the screen. X11, designed in the 1980s, has done that job for most of Linux's history. Wayland is its modern replacement, built around the idea that the compositor is in charge and applications are isolated from each other.

That isolation is the source of both its strengths and its friction. It prevents one application from reading another's window contents or capturing keystrokes, which is a real security gain. It also means tools that relied on the old open-door model, such as some screen recorders, automation scripts and remote-control utilities, need new, permission-aware approaches.

What was removed, and what remains

• Removed: the X11 session itself. You can no longer pick a GNOME-on-Xorg session at the login screen.
• Removed: X11 support from GDM, the login manager, which now runs entirely on Wayland.
• Kept: XWayland, a compatibility layer that lets older X11-only applications run as windows inside the Wayland desktop.

This change was originally planned for GNOME 49 but was pulled back at the last minute because of a bug, so GNOME 50 is where it actually landed.

Other improvements in GNOME 50

Coverage of the release highlights variable refresh rate enabled by default, better fractional scaling, and support for HDR in screen sharing. Variable refresh rate is especially welcome for gaming, where it reduces tearing without adding latency. Fractional scaling improvements help on high-resolution laptop panels, where integer scaling makes everything too large or too small.

How to check what you are running

Open a terminal and print the session type. On a Wayland desktop the answer is wayland. You can also see which applications are running through XWayland, which is useful for finding the programs that may need attention.

echo $XDG_SESSION_TYPE
# wayland

# Install xlsclients, then list apps running through XWayland:
xlsclients

What is most likely to break

• Tools that simulate keyboard and mouse input globally, such as xdotool-based scripts, generally do not work against native Wayland windows.
• Screen recording and screenshot tools must use the desktop's portal interface, and older tools that grab the screen directly will not work.
• Global hotkey utilities need to integrate with the compositor instead of grabbing keys themselves.
• Remote desktop software that was built around X11 needs a Wayland-aware version.

Most major applications have long since added Wayland support, and the portal system gives well-behaved tools a standard way to ask permission to record the screen or share a window.

If you really need X11

Other desktops are making different choices at different speeds. Several remain able to run X11 sessions, and some distributions will continue to offer them. Keep in mind that the broader ecosystem is moving the same way, so treating an X11 session as a permanent solution means you will eventually need to replace the tool that requires it.

What to do now

Before upgrading a work machine, list the tools you depend on, then test them in a live Wayland session or a virtual machine. Look for Wayland-native alternatives to anything that fails, and report bugs to the projects involved. The people who maintain these tools generally want to hear about real workflows that break.