Skip to content

$ cat ./posts/arch/wayland-on-arch-the-honest-state.md

-rw-r--r-- 1.7K #arch #wayland

Wayland on Arch: the honest state

by chris · 2 min read · /arch


Wayland is the default on most desktops now, and the remaining rough edges are specific enough to list. This is what a daily-driver setup looks like after a year, without the evangelism.

1. What is genuinely better

Per-monitor fractional scaling that works, no tearing without a compositor hack, and input handling that does not fall apart under load. Mixed-DPI setups in particular went from painful to unremarkable.

2. What still needs care

  • Screen sharing works through xdg-desktop-portal. Install the portal that matches your compositor, or the picker never appears.
  • Clipboard managers need wl-clipboard. Anything expecting X selections sees nothing.
  • Global hotkeys for non-focused applications are deliberately unavailable. Bind them in the compositor instead.
  • Remote X11 forwarding over SSH still requires Xwayland, which is fine but worth knowing before a debugging session.

3. The environment variables that matter

# ~/.config/environment.d/wayland.conf
ELECTRON_OZONE_PLATFORM_HINT=auto
MOZ_ENABLE_WAYLAND=1
QT_QPA_PLATFORM=wayland;xcb

The Qt fallback to xcb is intentional: a handful of applications still crash on the Wayland backend, and a semicolon costs less than a bug report.

4. How to tell what you are running

echo "$XDG_SESSION_TYPE"
xlsclients   # anything listed is running through Xwayland

Most surprises come from an application quietly using Xwayland while you assume otherwise. Check before blaming the compositor.

← cd .. fris@linux:~/blog$ man arch