X11 vs Wayland: Choosing Your Display Server

What This Guide Achieves

Explain the difference between Wayland and X11 display servers, when to use each, and how to switch between them.

The Problem (Windows User Perspective)

On Windows, you never think about the “display server” — it’s invisible. On Linux, there are two competing display servers: Wayland (newer, more secure) and X11/Xorg (older, more compatible). Your choice affects which automation tools work and how some apps behave.

Good news for Linux Mint Cinnamon users: Linux Mint 22.3 Cinnamon ships with X11/Xorg as the default — and only — session. No switching is needed. Zorin OS and other GNOME-based distros ship both Wayland and X11 sessions and default to Wayland.

Which One Am I On?

echo $XDG_SESSION_TYPE

x11 → You’re on X11/Xorg (this will be the result on Linux Mint Cinnamon)
wayland → You’re on Wayland

If you’re on Linux Mint Cinnamon, you’re already on X11. There is nothing to configure — skip to the When to Stay on X11 section to understand why.

Wayland vs X11 — Quick Comparison

Feature	X11 (Xorg)	Wayland
Age	~40 years old	~15 years old
Security model	Any app can read keystrokes and window contents from any other app	Each app is isolated — cannot snoop on other windows
Inter-app window access	`wmctrl`, `xdotool`, `xclip` can control/resize/read any window	Apps cannot programmatically access other apps’ windows (by design)
Performance	Good	Better (less screen tearing, smoother animations)
HiDPI scaling	Basic	Better
Compatibility	Everything works	Some older apps and X11-only tools don’t work
Screen sharing	Works everywhere	Some apps struggle; requires PipeWire/xdg-desktop-portal

Wayland’s security model is the key trade-off. On X11, any running app can read what you type into any other window and capture what’s on your screen — that’s how automation tools like xdotool work. Wayland intentionally blocks this for security. There are workarounds (PipeWire for screen capture, wl-clipboard for clipboard access, portals for file dialogs), but they add complexity and have not been tested on this setup.

When to Use X11 (Recommended for Most Users)

Use X11 if you:

Use wmctrl, xdotool, or xclip for automation
Run Stata or other apps that have Wayland bugs (window resizing issues)
Need screen recording or screen sharing in apps like Zoom
Use any tool that needs to control other windows programmatically

When to Use Wayland

Use Wayland if you:

Want the latest security and performance improvements
Don’t use any X11-specific automation tools
Have a HiDPI display and want better scaling

How to Switch (Zorin OS and Other GNOME/GDM Distros)

Linux Mint Cinnamon users: This section does not apply to you. Linux Mint uses LightDM and ships only X11/Xorg — there is no Wayland session to switch away from.

Log out of your current session
On the login screen, click on your username
Look for a gear icon (usually bottom-right corner)
Select the X11/Xorg session if you need maximum compatibility. The exact label names vary by distro — look for an option containing “Xorg” in the session name (e.g. “Ubuntu on Xorg”).
Enter your password and log in

Making It Permanent

The selection persists between reboots — whichever you chose last will be used on next login.

Known Issues with Wayland (Observed on Zorin OS 18.1 Pro)

These issues were encountered when testing Wayland on Zorin OS 18.1 Pro (GNOME/GDM). They do not affect Linux Mint 22.3 Cinnamon, which runs X11 by default.

Issue	Description
Stata window resizing	GTK bug causes Stata GUI to not resize properly under Wayland
wmctrl/xdotool don’t work	These X11-only tools fail silently on Wayland
xclip doesn’t work	Clipboard automation requires X11 — use `wl-clipboard` on Wayland instead
Some Electron apps	Older Electron apps may have rendering issues

Forcing an App to Use X11 on Wayland

If you’re on Wayland but need one specific app to use X11:

GDK_BACKEND=x11 stata-mp

Or add it permanently to the app’s .desktop file:

Exec=env GDK_BACKEND=x11 stata-mp

What Didn’t Work (and Why)

Approach	Why It Failed
Using Wayland with wmctrl/xdotool automation scripts	These tools rely on X11’s permissive window access. Wayland blocks cross-app window control by design.
Running Stata on Wayland (Zorin OS)	Window resizing GTK bug — must force X11 backend with `GDK_BACKEND=x11`
Assuming all apps work on both	Some apps (especially older ones and automation tools) only work properly on X11
Trying Wayland workarounds (PipeWire, portals, wl-clipboard)	These exist and may work, but have not been tested on this setup — no verified workflow exists yet

Emergency: “Oh No! Something Has Gone Wrong” After a System Update (Zorin OS / GNOME + GDM3)

Linux Mint Cinnamon users: This issue is specific to GNOME-based distros that use GDM3 (Zorin OS, Ubuntu). Linux Mint uses LightDM and ships only X11 — this crash scenario does not apply.

After a routine sudo apt upgrade, Zorin OS (and other Ubuntu-based GNOME desktops) can boot into a red fail-safe screen:

“Oh no! Something has gone wrong. A problem has occurred and the system can’t recover.”

The graphical desktop refuses to load entirely. This is GNOME’s crash screen — it means the display manager (GDM3) failed during initialization, usually because a kernel or Mesa graphics update broke Wayland compatibility with the hardware.

What the Logs Show

Access a virtual terminal with Ctrl+Alt+F3 (try F4, F5, or F6 if F3 doesn’t respond), log in with your username and password, then run:

journalctl -p 3 -xb

The relevant lines look like this (truncated in the terminal output):

gdm3[2365]: Gdm: on_display_added: assertion failed
systemd[3295]: Failed to start app-gn...
systemd[3295]: Failed to start app-gn...

GDM3 crashes the moment it tries to draw the login interface. The VMX (outside TXT) and bluetoothd sap-server: Operation not permitted errors that also appear are background noise present on most ThinkPads — they are not the cause.

Step 1: Rule Out the Simple Causes First

Check disk space

If / or /home is at 100%, GNOME won’t load. Check first:

df -h

If Use% on any partition is at 100%, free up space before proceeding.

Restore home directory permissions

A permissions shift during a system update or data transfer can prevent GNOME from reading its own config files:

sudo chown -R $USER:$USER /home/$USER
sudo systemctl restart gdm3

Disable all GNOME extensions

Extensions break frequently after updates and are a common culprit:

gsettings set org.gnome.shell disable-user-extensions true
sudo systemctl restart gdm3

Step 2: Disable Wayland at the GDM Level

If the steps above didn’t resolve the crash, the root cause is a Wayland/GDM3 conflict. The fix is to force GDM to always start an Xorg session instead of Wayland.

1. Open the GDM configuration file:

sudo nano /etc/gdm3/custom.conf

2. Find the commented-out line:

#WaylandEnable=false

3. Remove the # to uncomment it:

WaylandEnable=false

4. Save and exit:

Press Ctrl+O, then Enter to save. Press Ctrl+X to exit.

5. Restart the display manager:

sudo systemctl restart gdm3

The fail-safe screen will not appear again. GDM will now always start an Xorg session, bypassing the Wayland protocol conflict entirely.

To re-enable Wayland later: Re-comment the line (#WaylandEnable=false) in /etc/gdm3/custom.conf and restart GDM. This change applies system-wide — it affects the login screen and all user sessions, not just your own.

What Didn’t Work

Approach	Why
Rebooting	GDM retries Wayland on every boot — same crash every time
Waiting for the next update	Wayland remains broken until the upstream kernel/driver conflict is resolved
Clearing GNOME settings (`mv ~/.config/dconf/user ~/.config/dconf/user.bak`)	Worth trying, but didn’t resolve this particular case — the root cause was the display protocol conflict, not a corrupted GNOME setting

System Requirements — Why X11 was chosen for this setup
Stata 19 Complete Guide — Wayland resize bug fix
VS Code Setup — Automation tools that require X11