Fedora Workstation’s Wayland Default: Why It Matters and How to Verify

Fedora Workstation’s Wayland Default: Why It Matters and How to Verify

When you log into a fresh Fedora Workstation install, the GNOME session you see is most likely running on Wayland rather than the older Xorg server. This shift changes how input events are handled, how the compositor draws frames, and what tools you can use for screen capture or remote desktop. Knowing whether you are on Wayland helps you troubleshoot compatibility issues and decide if you need to switch back to Xorg for certain workloads.

Why Fedora Chose Wayland as the Default

The Fedora Workstation team made Wayland the default for the GNOME Shell session to address three practical concerns:

• Input isolation. Wayland separates client input handling, reducing the risk that a malicious application can sniff keystrokes from other windows.
• Reduced tearing and smoother rendering. The compositor (mutter) presents frames directly, eliminating the need for a separate X server to manage buffers.
• Better HiDPI support. Fractional scaling and per-monitor DPI settings are handled natively, which is increasingly important on modern laptops and high-resolution displays.

To keep existing X11 software functional, Fedora relies on XWayland, a compatibility layer that translates X11 protocol calls into Wayland surface operations. Most legacy applications run unchanged through this bridge.

How the Default Session Is Started

At boot, the GDM display manager reads its configuration and, unless a proprietary NVIDIA driver is detected, launches the gnome-wayland session. This session starts mutter as the Wayland compositor, which also acts as the window manager. The session type is communicated to client applications via the XDG_SESSION_TYPE environment variable.

If you need to force Xorg—for example, to use a driver that lacks Wayland support—you can edit /etc/gdm/custom.conf and set:

[daemon]
# Uncomment the line below to force the classic Xorg session
WaylandEnable=false

After saving the file, restart GDM (sudo systemctl restart gdm) or reboot the machine. This change affects all users logging in through GDM.

Verifying That You Are Running Wayland

The simplest check is to examine the session type variable from a terminal:

echo $XDG_SESSION_TYPE

You should see wayland when using the default GNOME session. If the output is x11, you are running an Xorg session (either chosen at the login screen or forced via custom.conf).

For a deeper look, inspect the GDM logs:

journalctl -u gdm | grep -i 'gnome wayland'

Look for a line similar to Starting GNOME Wayland session on display :0. Alternatively, the per-display log at /var/log/gdm/:0.log contains the session type near the start of the file.

You can also confirm that a Wayland compositor is active with the looking-glass tool (part of the gnome-shell package) or the standalone weston-info utility:

looking-glass

The window that appears will show the compositor name (mutter) and its version. Running weston-info prints information such as Wayland compositor: mutter and the supported protocols.

These checks require no special privileges; they can be run by any user in a standard terminal session.

Trade-offs and Limitations

While Wayland brings security and usability gains, there are still scenarios where Xorg remains preferable:

• Proprietary NVIDIA drivers. The legacy 304.xx and 340.xx series lack full Wayland support; Fedora automatically falls back to Xorg when these drivers are detected. If you manually install a newer driver that still has gaps, you may need to enable Xorg via custom.conf.
• Screen-recording and remote-desktop tools. Applications that depend on X11 extensions (e.g., Xtest, XShm) must run under XWayland or be ported to Wayland protocols such as xdg-desktop-portal. Some older versions of OBS Studio or VNC servers may need extra configuration.
• Accessibility utilities. Certain screen readers or magnifiers that hook into the X server may not work under Wayland until they are updated to use the AT-SPI2 over DBus interface.

You can verify whether a specific tool works by launching it and checking its output or logs; if it fails to capture input or display, try launching the same tool from an Xorg session (choose GNOME on Xorg at the login screen) and compare behavior.

Actionable Next Steps

If you are satisfied with Wayland, keep the default configuration and enjoy the improved input security and smoother graphics. If you encounter a workflow that depends on an X11-only feature, consider the following:

1. Log out, click your username on the GDM greeter, and select the GNOME on Xorg session to test whether the issue disappears.
2. If the Xorg session resolves the problem, decide whether to keep using Xorg for that workload or to seek a Wayland-native alternative (e.g., OBS Studio with the wayland backend, or gnome-shell screencast via dbus).
3. For system-wide enforcement of Xorg, edit /etc/gdm/custom.conf as shown above, restart GDM, and verify with echo $XDG_SESSION_TYPE that the variable now reads x11.

Remember that switching the default session changes the environment for all future GDM logins, so inform other users of the workstation if you make this change.