The login screen choice
You boot into Fedora and the login screen asks for your password. In the bottom-right corner, a small gear icon waits. You click it, see "GNOME on Wayland" and "GNOME on Xorg", and wonder which one actually matters. You pick the wrong one, log in, and your secondary monitor goes black or your GPU recording software throws a segmentation fault. The session type dictates how your desktop draws windows, handles input, and talks to the GPU. Getting it right saves you from chasing phantom bugs.
Log out completely before you switch. A locked screen does not reset the display server. A fresh login forces GDM to initialize the compositor and load the correct input stack.
What Wayland and X11 actually do
X11 has been the standard display protocol for Linux since the early 1990s. It works like a shared whiteboard. Every application draws directly onto the screen buffer, and the window manager rearranges the pieces. That design is flexible but exposes every running process to every other process. Keyloggers, screen scrapers, and misbehaving apps can read your keystrokes or capture your entire screen without asking. The protocol also routes input events through the window manager, which means the compositor can intercept or delay keyboard and mouse actions.
Wayland changes the architecture. It acts as a strict gatekeeper. Each application gets its own private window buffer. The compositor alone decides what gets drawn to the physical screen. Input events go straight from the kernel to the target application, bypassing the window manager entirely. Think of X11 as an open office where anyone can walk to any desk. Wayland is a reception desk that routes calls and deliveries to the exact person who needs them.
Fedora defaults to Wayland because the security model matches modern desktop expectations. Touch input, multi-monitor scaling, and fractional scaling also work natively without workarounds. The tradeoff is compatibility. Some older tools, certain NVIDIA driver configurations, and specific screen-sharing workflows still expect the shared buffer model that X11 provides.
Convention aside: Fedora ships both sessions in the base gnome-session package. You do not need to install extra metapackages to switch. The gear icon at the GDM login screen is the official interface. Editing systemd user records or forcing session types via CLI is reserved for automated deployments and containerized desktops. Stick to the gear icon for daily use.
Reboot only if the login manager itself crashes. Session switches happen instantly at the display manager level.
How to switch session types
The graphical method is the standard path. Log out completely. At the GDM login prompt, locate the gear icon in the lower-right corner. Click it and select "GNOME on Xorg" if you need legacy compatibility, or "GNOME on Wayland" for the default secure stack. Enter your password and log in. The choice applies only to that login session. You can switch back and forth as often as needed without rebooting.
If you are managing a headless server that occasionally needs a desktop, or you are scripting a test environment, you can verify and influence the session type through systemd user records. The systemd-user-record tool stores per-user preferences in JSON format. You can set a preferred session type that GDM will honor when available.
# Create a temporary user record to set the preferred display server
systemd-user-record create '{"type":"regular","name":"$USER","preferredSessionType":"x11"}' > /tmp/session-record.json
# Import the record into the systemd user database
systemd-user-record update /tmp/session-record.json
# Remove the temporary file after successful import
rm /tmp/session-record.json
This approach writes to the systemd user database rather than modifying configuration files in /etc/. The database survives package updates and does not conflict with system-wide defaults. Use it only when the GUI gear icon is unavailable or when you are provisioning machines at scale.
Convention aside: Never edit files in /usr/lib/ to force session behavior. Those files ship with the package and get overwritten on every dnf upgrade --refresh. User modifications belong in /etc/ or in the systemd user database. Manual file edits drift, snapshots stay.
Verify your active session
After logging in, confirm which display server is actually running. The desktop environment can sometimes fall back to X11 automatically if Wayland fails to initialize, and the gear icon selection does not always guarantee the final result.
# Query the active session type from systemd-logind
loginctl show-session $(loginctl | grep $(whoami) | awk '{print $1}') -p Type
# Check the environment variable set by the display manager
echo $XDG_SESSION_TYPE
# Verify the compositor process running in the background
ps aux | grep -E '(gnome-shell|mutter)' | grep -v grep
The loginctl command reads directly from the logind database and returns Type=wayland or Type=x11. The XDG_SESSION_TYPE environment variable is set by GDM at login and is used by applications to adjust their rendering pipeline. Cross-reference both values. If they disagree, the session is in a transitional state. Log out and log back in to force a clean initialization.
Convention aside: Run journalctl -xeu gdm before you guess. The x flag adds explanatory text and the e flag jumps to the end. Most sysadmins type this muscle-memory style when the login screen misbehaves. Read the actual error before guessing.
Common pitfalls and error symptoms
Switching display servers changes how input, scaling, and screen capture work. Expect specific failure modes when the wrong session is active.
Fractional scaling breaks on X11. GNOME's fractional scaling feature relies on Wayland's native buffer management. If you enable 125 percent or 150 percent scaling and log into X11, the desktop will snap to 100 percent or 200 percent. Text will look blurry or oversized. Switch to Wayland to restore the exact scaling ratio.
Screen recording and streaming software may fail to capture the desktop. OBS Studio and similar tools use the PipeWire portal on Wayland. If you see a black screen or a Failed to create screen capture source error, you are likely running X11 without the X11 grab plugin, or you are running Wayland without granting the application screen capture permissions. Check GNOME Settings under Privacy and Sharing to verify application permissions.
NVIDIA proprietary drivers historically required X11 for full functionality. Modern Fedora releases ship with updated NVIDIA packages that support Wayland compositing and DRM kernel modesetting. If you experience tearing, black screens, or glxinfo returning zero for OpenGL renderer string, verify that the nvidia-driver package is installed and that secure boot is either disabled or signed with your MOK keys. Run dnf upgrade --refresh before testing. The --refresh flag forces metadata validation and pulls the latest driver patches from the Fedora repositories.
Virtual machine clipboard sharing and drag-and-drop often fail on Wayland. The clipboard portal works for plain text and basic image formats. Complex drag-and-drop operations between host and guest require X11 or specific QEMU/Virtio-GPU configurations. If your VM workflow depends on seamless file dragging, log into X11 for that specific session.
When GDM refuses to start Wayland and drops you to a text console, you will see this exact message in the journal:
Failed to start GNOME Display Manager.
gdm-wayland-session: error: Failed to connect to Wayland display
The compositor failed to initialize, usually because of a missing GPU firmware blob or a broken mutter package. Switch to Xorg at the gear icon, log in, and run dnf upgrade --refresh to pull the matching firmware and compositor updates. Do not force Wayland until the package manager resolves the dependency chain.
Snapshot the system before the upgrade. Future-you will thank you.
Choose your display server
The choice between display servers depends on your hardware, your workflow, and your tolerance for compatibility workarounds.
Use Wayland when you want a secure desktop that isolates application buffers and routes input directly to the target window. Use Wayland when you need fractional scaling, native touch input, or modern screen-sharing portals. Use Xorg when you run legacy enterprise applications that depend on X11 extension APIs like XInput2 or XTest. Use Xorg when you require seamless clipboard and drag-and-drop integration with virtual machines. Use Xorg when your NVIDIA hardware predates the DRM kernel modesetting updates and refuses to composite correctly. Stay on the default Wayland session if you only deviate from the standard GNOME stack occasionally.
Trust the package manager. Manual file edits drift, snapshots stay.