PCSX2 Disables Wayland Support

Original Article ↗ Hacker News Discussion ↗

PCSX2’s decision to disable Wayland support in its release builds reignites long‑running tensions over the Linux desktop’s graphical stack, especially the trade‑offs between legacy X11 and the newer Wayland protocol. Commenters highlight real benefits of Wayland—better scaling, security, and modern GPU handling—but argue that incomplete protocols, compositor fragmentation (notably GNOME vs KDE vs wlroots), and broken or missing features like window placement and multi‑window workflows make life difficult for both users and developers. Many see XWayland as a necessary crutch for now, while others worry that slow, committee‑driven evolution and opinionated design choices could lock desktop Linux into a permanently awkward transition state.

Context: PCSX2 Disables Wayland by Default

  • PCSX2 disables Wayland in release builds due to frequent bugs and user reports they attribute to compositor and protocol issues, not their own code.
  • Maintainers complain about being blamed for compositor bugs and slow, contentious protocol evolution (e.g., window placement), with some compositors refusing to implement agreed extensions.
  • App still works via XWayland; the change mainly drops native Wayland as default.

Wayland vs X11: Readiness and “Sunk Cost”

  • One side: Wayland has improved rapidly in the last few years, is default on major distros, handles HiDPI, mixed DPI, tearing, and modern features better, and X11 is effectively design‑dead.
  • Other side: Wayland has been “almost ready” for a decade, still lacks mature support for many workflows; both X11 and Wayland now carry their own legacies.

Compositor Fragmentation (GNOME, KDE, wlroots, Weston)

  • KDE and GNOME ship their own Wayland stacks; wlroots-based compositors (Sway, Hyprland, etc.) are cited as a “gold standard.”
  • Some report PCSX2 and mpv working well on wlroots/KDE but “janky” or unusable on GNOME.
  • Weston and wlroots devs NACKed a proposed window-placement protocol; it was relegated to an experimental namespace.

Design Philosophy Conflicts

  • Wayland intentionally restricts things X11 allowed: absolute window positioning, global shortcuts, arbitrary key remapping, easy input snooping, and multi-window control.
  • Supporters: this improves security, avoids malicious/janky behavior, and keeps the protocol clean; compositors or portals should provide higher-level features.
  • Critics: desktop apps on Windows/macOS/X11 routinely rely on these capabilities (multi-viewport UIs, palettes, window restore, remote desktop); refusing them makes Linux a “weird island.”

Developer Experience & Governance

  • Complaints about slow, committee-driven protocol changes (e.g., screen capture, fractional scaling, vsync, placement) and GNOME deviating or refusing certain features.
  • Some argue Wayland centralizes too little (unlike systemd), forcing every compositor to reinvent common tools and CLIs.

User Experience Reports

  • Many report Wayland “just works,” often better than X11, especially on Intel/AMD and non-gaming workloads.
  • Others report severe breakage: multi-monitor chaos, fractional scaling issues, screen sharing/recording pain, Nvidia instability, and missing legacy tweaks (XCompose, Xmodmap, Unclutter).
  • Recurrent theme: it’s fine for “most users,” but edge cases (often power users, gamers, multi-window/pro apps) hit hard limitations.