Wayland vs X11 for ricing: what changes and what to use

Build a new rice on Wayland. GNOME 50 and Plasma 6.8 no longer ship an X11 session, the tiling compositors we cover most (Hyprland, sway and niri) are Wayland-only, and Xwayland runs the X11 apps you still need. What changes is the toolbox, not the look: a handful of X11 programs have Wayland counterparts, and a few jobs move into the compositor itself. Stay on X11 if your setup is built on i3, bspwm or another X11 window manager you don’t want to give up, or if a tool you depend on has no Wayland version yet.

This explainer was written against GNOME 50, Plasma 6.8, sway 1.12 and niri 26.04. Each project’s own docs have the final word on anything newer.

What actually changes for a rice

On X11, one server, Xorg, draws everything. The window manager, the compositor (picom, usually) and the bar are separate programs that all talk to it, and any program can read the screen, the keyboard and other windows.

On Wayland, the compositor is the display server and the window manager in one, and it draws the effects too: Hyprland, sway, niri, KWin on Plasma and Mutter on GNOME. That one change explains most of what you’ll notice:

• Effects belong to the compositor. Blur, shadows, rounded corners and animations come with the compositor you choose, not from a program you add.
• Settings move into its config. Screen layout, keyboard options and often the wallpaper go in the compositor’s config instead of xrandr, setxkbmap and feh lines in a startup script.
• Apps can’t reach into each other. A program can’t read another window’s contents or keystrokes. Screenshots, automation and screen sharing go through protocols the compositor offers, so a tool may work on one compositor and not on another.

Where each desktop stands

KDE’s Plasma 6.8 announcement says X11 apps keep working through Xwayland and KDE’s own apps keep supporting X11 for the foreseeable future. GNOME’s plan, set out in a developer’s write-up of the X11 session removal, left Xwayland untouched too. Xfce added preliminary Wayland support in 4.20 but keeps its window manager, xfwm4, X11-only, and Linux Mint’s lead has said the next Cinnamon, due with Mint 23 at the end of 2026, fully supports both sessions.

The tool swaps, side by side

Most of a rice survives the move: your terminal, your editor, your shell, your fonts and your palette don’t care which display server is underneath. These are the jobs where the X11 tool has to change.

A few of these need a word more:

• polybar has no native Wayland support, so its job goes to Waybar: a JSON config, CSS for the look, and modules that know the workspaces of sway, Hyprland and niri.
• rofi 2.0 added official Wayland support, so a rofi theme you’ve spent evenings on can come with you.
• Screen layout moves into the compositor’s config. On sway that means output lines, worked through in our guide to multiple monitors in sway, with kanshi switching layouts when you dock.
• wtype and wlr-randr rely on protocols that wlroots compositors like sway implement and GNOME does not. ydotool works anywhere, through the kernel’s uinput, but needs its ydotoold daemon running with access to /dev/uinput.
• GNOME and Plasma have their own screenshot, display and night light tools, so on those desktops you mostly use their settings instead.

sway’s i3 migration guide keeps a longer list of X11 programs and their Wayland counterparts, down to xev and xprop. The bars, launchers and notification daemons above that we’d start with are in the Toolkit, each linked to its project page.

Your colors are the easy part. The Generator writes theme files for Polybar and Waybar, rofi and fuzzel, and i3, sway and Hyprland from one palette, so the move from an X11 rice to a Wayland one keeps the same colors.

Effects without picom

On X11, picom gave you shadows, fading, transparency, blur, rounded corners and, in recent versions, animations. On Wayland each of those is a setting in the compositor, and the compositors differ a lot:

• Hyprland has blur, shadows, rounded corners, per-window opacity and animations built in: the pick if you want motion.
• KWin, on Plasma, has blur and a long list of desktop effects you switch on in System Settings.
• niri draws rounded corners, shadows and animations, and since 26.04 it blurs behind windows that ask for it through the ext-background-effect protocol, or behind any window you name in a window rule.
• sway stays deliberately plain: no blur, shadows or rounded corners. SwayFX, a fork, adds blur, rounded corners, shadows and dimmed unfocused windows on top of sway’s config.
• GNOME animates on its own; blur and most other effects come from shell extensions.

Tip: the classic transparent terminal is two settings now, not one program. Give the terminal some transparency in its own config, then let the compositor blur what shows through.

If the effects decide it for you, our comparison of Hyprland, sway, niri and i3 sets out how each one tiles, what it draws and how it’s configured.

Xwayland and the apps that still need X11

Xwayland is an X server that runs inside your Wayland session, so X11 apps open in it like any other window. sway, Hyprland, KWin and Mutter start it for you. niri, since 25.08, starts xwayland-satellite the moment an X11 app connects, as long as version 0.7 or later is installed.

What still goes through it is shrinking but real: Electron apps built before Electron 38.2, most Java apps (OpenJDK has no native Wayland support yet, though JetBrains IDEs ship their own), many games and older apps nobody has ported. To see which ones you’re running:

• xlsclients -l lists every client connected to Xwayland.
• In sway, swaymsg -t get_tree marks each window’s "shell" as xdg_shell or xwayland.
• In Hyprland, hyprctl clients shows xwayland: 1 for X11 windows.
• xeyes works anywhere: the eyes follow the pointer only over X11 windows.

Three things behave differently for those apps:

1. Scaling. On a scaled screen, X11 apps draw at scale 1 and the compositor stretches them, so they look blurry. sway doesn’t support HiDPI for Xwayland at all; Hyprland’s force_zero_scaling option and Plasma’s display setting for legacy X11 apps let them draw at full resolution instead, small but sharp.
2. Global hotkeys. An X11 app only sees keys pressed while an X11 window has focus, so a push-to-talk key in an X11 chat app goes quiet when your terminal is focused. Bind the key in your compositor, or use a native Wayland build that supports the desktop portal’s global shortcuts.
3. Screen capture. An X11 recorder only sees other X11 windows. Native Wayland apps share the screen through PipeWire and xdg-desktop-portal, which needs your compositor’s backend installed: xdg-desktop-portal-wlr for sway and other wlroots compositors, xdg-desktop-portal-hyprland for Hyprland. GNOME and Plasma ship their own. A black screen or no window picker in a video call usually means the backend is missing.

When X11 is still the right call

Wayland is the default for a new rice, not a rule. X11 still makes sense when:

• Your window manager is X11-only and you love it. sway reads most of an i3 config, but bspwm, awesome and dwm have no drop-in Wayland twin. Compositors inspired by them, such as river-classic and dwl, are a rebuild, not a migration.
• A script or tool you rely on has no Wayland counterpart. xdotool scripts that find, move or inspect other apps’ windows are the usual one: wtype only types, and the compositor’s IPC only knows its own commands.
• Your GPU is on an old driver. NVIDIA drivers before 470 don’t accelerate Xwayland at all, and a card dropped from NVIDIA’s current driver is better served by Xorg or nouveau.
• You want the X11 Plasma you have for a while longer. Plasma 6.7’s X11 session is supported into early 2027, and KDE itself points to long-term distributions like AlmaLinux 9, which ships the Plasma X11 session until 2032.

None of that is a reason to rush. An i3 rice that works keeps working on Xorg; you can try sway beside it from the login screen and move over when it suits you.

Check which one you’re running

1. Open a terminal and run:

   echo $XDG_SESSION_TYPE

   It prints wayland or x11.

2. If it prints tty, you started the compositor from a console login. Check the Wayland socket instead:

   echo $WAYLAND_DISPLAY

   A value starting with wayland- means you’re on Wayland.

3. List the apps still going through Xwayland with xlsclients -l (it ships in a package called xorg-xlsclients or x11-utils, depending on the distro).

Once you know where you stand, the rest of the system under the rice, from distributions to drivers, is in Linux.