When Wayland breaks your workflow
You install Fedora Workstation and everything looks great until you launch a specific application. Maybe it is a game with kernel-level anti-cheat, a remote desktop client, or a legacy graphics tool. The window renders with black artifacts, crashes immediately, or refuses to start. You check the terminal output and see display server incompatibilities. The system is running Wayland by default. You need Xorg.
What is actually happening
Fedora uses GDM as the display manager. GDM handles the login screen and negotiates which display server should run your desktop session. Wayland is the modern default because it isolates applications, improves touchpad gestures, and reduces input latency. Xorg is the older protocol. It runs as a single privileged process that handles all input and output. Some hardware drivers and older software still expect that centralized model.
The architecture difference matters. Wayland runs a separate compositor for each user session. Applications only draw to their own buffers. The compositor merges them and sends the final frame to the GPU. Xorg runs one global server that manages every window, keyboard event, and mouse movement. That single point of control makes Xorg easier to debug for legacy software. It also means any application can theoretically spy on your keystrokes or capture your entire screen. Fedora chose Wayland for security and performance. You are opting out of those defaults to gain compatibility.
When you force Xorg, you are telling GDM to skip the Wayland session and launch the X11 backend instead. The configuration lives in /etc/gdm/custom.conf. Files in /etc/ are yours to modify. Files in /usr/lib/ ship with the package and get overwritten on updates. Always edit /etc/. GDM reads this file on startup and applies the daemon-level overrides before presenting the login screen.
Change the default session before you log in. GDM caches the last used session, but a global config guarantees consistency across reboots.
How to switch to Xorg permanently
You need to create or modify the GDM override file. The file uses a standard INI format. The [daemon] section controls GDM behavior. The WaylandEnable key accepts boolean values. Setting it to false disables the Wayland session option entirely.
Here is how to write the configuration file safely without opening a graphical editor.
# Create the directory if it does not exist yet
sudo mkdir -p /etc/gdm
# Write the override file and suppress stdout to keep the terminal clean
sudo tee /etc/gdm/custom.conf > /dev/null <<EOF
[daemon]
# Disable Wayland sessions system-wide
WaylandEnable=false
EOF
# Restart GDM to apply the change immediately without a full reboot
sudo systemctl restart gdm
The systemctl restart gdm command drops you back to the login screen. Your active session will close. Save any open work before running it. If you prefer a full reboot, replace the restart command with sudo reboot.
Reboot before you debug. Half the time the symptom is gone.
Verify the session type
Logging in is not enough proof. You need to confirm the display server actually changed. Open a terminal after you log in and check the environment variable that tracks the session type.
# Print the current display server protocol
echo $XDG_SESSION_TYPE
The output will be x11. If it prints wayland, the configuration did not apply. Check the file syntax. A missing [daemon] header or a typo in WaylandEnable will cause GDM to ignore the setting.
You can also verify the running service state. GDM spawns different backend processes depending on the session type. Checking the service status shows you which process tree is active.
# Show GDM state and recent log lines in one view
systemctl status gdm
Look for Active: active (running) and scan the recent journal lines for Xorg references. If you see wayland or mutter in the active process list, the override failed.
Run echo $XDG_SESSION_TYPE first. Trust the variable, not the window manager behavior.
Common pitfalls and error patterns
Forcing Xorg can trigger a login loop. You type your password, the screen flickers, and you return to the GDM prompt. This usually happens when the Xorg backend cannot initialize your GPU driver, or when a user-level configuration overrides the system setting.
If you hit a login loop, press Ctrl + Alt + F3 to drop to a virtual console. Log in with your username and password. Check the GDM logs for the actual failure reason.
# Show recent GDM logs with explanatory hints and jump to the end
journalctl -xeu gdm
Look for lines mentioning Xorg or EE (error) in the output. If you see Failed to load module "nvidia", your proprietary driver is missing or mismatched. Install the correct driver package before retrying. If you see permission errors on ~/.Xauthority or ~/.ICEauthority, delete those files. Xorg will recreate them on the next login.
# Remove stale X11 authentication files that block session startup
rm -f ~/.Xauthority ~/.ICEauthority
# Restart GDM to test the clean state
sudo systemctl restart gdm
Another common issue is the gear icon at the login screen. GDM shows a session selector by default. If you click the gear and choose "GNOME on Xorg", you are applying a per-user override. That override persists until you change it again. The /etc/gdm/custom.conf file removes the gear option entirely and forces Xorg for every user. Pick one method. Do not mix global config with per-user selection.
Read the actual error before guessing. journalctl -xe tells you exactly which module failed.
How to revert to Wayland
You do not need to reinstall anything to switch back. Remove the override line or set it to true. GDM will fall back to the package default on the next restart.
# Restore the default Wayland behavior
sudo tee /etc/gdm/custom.conf > /dev/null <<EOF
[daemon]
WaylandEnable=true
EOF
# Apply the change
sudo systemctl restart gdm
You can also delete the file entirely. GDM ships with sensible defaults in /usr/lib/. The /etc/ file is purely an override layer. Removing it returns control to the package maintainer.
Trust the package manager. Manual file edits drift, snapshots stay.
When to use Xorg versus Wayland
Fedora ships with Wayland enabled by default for a reason. The protocol improves security by sandboxing each application. It reduces input latency for gaming and creative work. It handles multiple monitors with different refresh rates more gracefully. Switching to Xorg is a trade-off. You gain compatibility with legacy software and certain GPU drivers. You lose modern input handling and application isolation.
Use Xorg when you run software that requires direct X11 access, such as older remote desktop clients or applications with kernel-level anti-cheat. Use Xorg when your NVIDIA driver version predates Wayland support and you cannot upgrade due to hardware limitations. Use Wayland when you want modern security boundaries, smooth touchpad gestures, and better multi-monitor scaling. Use a custom Wayland compositor like Sway when you prefer a tiling workflow and do not need GNOME features. Stay on the default Wayland session if your hardware works correctly and you only need standard desktop functionality.
Match the display server to your workload. Do not fight the default unless the workload demands it.