Wayland vs. X – Overview

Original Article ↗ Hacker News Discussion ↗

Wayland’s push to replace the aging X11 window system on Linux is exposing a trade-off between security, modern features and the flexibility many users are used to. Commenters report wildly different experiences: for some, Wayland delivers smooth multi-monitor setups, fractional scaling and tear‑free graphics, while others hit show‑stopping issues with games, remote apps, screen sharing or input tools like Barrier—often depending on GPU drivers, distro, and compositor. A recurring theme is fragmentation: there is no single “Wayland,” but many incompatible compositors and protocols, which complicates porting features that worked uniformly under X11 and slows broader adoption.

Overall experiences: Wayland vs X

  • Many report Wayland “just works”: smooth multi-monitor (including rotation), no tearing, usable fractional scaling, working screenshots and screen sharing.
  • Others report severe breakage: slow performance, broken fractional scaling, crashes, weird display artifacts, high CPU/heat, fullscreen apps (VLC, games) misbehaving.
  • Several say X11 + lightweight WMs (XFCE, i3, openbox) are rock-solid, fast, and resource‑light, with fewer surprises.

Hardware, drivers, and distros

  • Wayland is often described as working best with Intel/AMD GPUs using modern drivers; Nvidia and older AMD (“radeon”) setups are frequent pain points.
  • Some suggest issues may stem from GPU drivers or distro integration rather than Wayland itself.
  • Fedora is often cited as a “forward-looking” distro where Wayland works out of the box; Ubuntu is described as more hit‑or‑miss. Pop!_OS defaults to X but can be hacked to run GNOME on Wayland.

Fragmentation: “Waylands” vs X

  • A recurring theme: “there is no single Wayland” but multiple compositors (GNOME, KDE, wlroots/Sway, Gamescope, etc.) with differing capabilities and extension choices.
  • This diversity is seen by some as modular and “Linuxy”; others see it as fragmentation that complicates app support and user expectations.
  • Example: some compositors use libei for input emulation (for tools like Barrier), while others reject it, so features vary by compositor.

Features, limitations, and security

  • Wayland’s security model intentionally blocks arbitrary input snooping/injection; enabling controlled versions (e.g., through libei) is nontrivial work.
  • Critics feel “missing features in the name of security” clashes with the traditional emphasis on flexibility and customizability.
  • Screen sharing and screenshots are said to work fine for many, but some still can’t get them working (e.g., Discord via Electron, XWayland interactions).

Remote graphics and cross‑platform

  • X’s built‑in remote windowing via SSH is valued; Wayland deliberately leaves remote rendering out of scope.
  • Remote use is possible via tools like waypipe or RDP/virtio-style setups, but requires extra configuration; some consider this a deal‑breaker.
  • Concern is raised that Wayland is primarily Linux‑centric; X’s broader portability (including Windows/macOS servers) is noted, though Wayland does run on some BSDs.

Adoption, perception, and evolution

  • Early negative experiences with Wayland still color opinions, even though many believe it has improved significantly.
  • Some expect eventual migration as X11 stagnates; others are content to stay on X for stability and mature workflows.