Hard numbers in the Wayland vs. X11 input latency discussion

Original Article ↗ Hacker News Discussion ↗

Measurement & Significance

  • OP measured end‑to‑end cursor latency with a high‑FPS phone camera, finding 1 extra 144 Hz frame (6.5 ms) on GNOME Wayland vs GNOME X11.
  • Several commenters say this end‑to‑end approach is exactly what users care about; others call the methodology “rough” and suggest hardware‑timed setups (photodiodes, Arduinos, LDAT) for cleaner data.
  • A quick statistical check in the thread finds the difference highly significant (very low p‑value), so it’s unlikely to be pure noise.

GNOME vs “Wayland in general”

  • Many stress the result only applies to GNOME’s Mutter compositor; Wayland is just a protocol.
  • Others counter that in practice the dominant compositors become de‑facto standards, so GNOME’s issues matter for “Wayland” as users experience it.
  • Some request repeats on KDE, wlroots/Sway, Gamescope; one person shares their own hardware measurement showing similar “Wayland a bit slower than X11” on KDE and Sway.

Probable Technical Causes

  • Strong suspicion that the extra frame comes from compositor behavior: vsync, buffering, and atomic KMS updates.
  • Explanations focus on:
    • Wayland compositors doing atomic, vsync‑synchronized cursor updates vs X11’s historically more “as‑soon‑as‑possible” hardware cursor updates, even mid‑scanout (accepting tearing).
    • Cursor throttling and lack of “race the beam” techniques.
    • Cases where hardware cursor planes aren’t used or are constrained by drivers (AMD/Nvidia quirks, atomic DRM path).
  • Several people note full‑screen games can bypass or minimize compositor latency via direct scanout or game‑driven cursors, so desktop cursor results may not map directly to in‑game latency.

Gaming and Human Perception

  • Debate over whether ~6–7 ms matters: some call it imperceptible for most, others cite research and gaming experiments suggesting small latency differences measurably affect win rates, “feel,” and rhythm/timing tasks.
  • Some Linux gamers report no noticeable downside on Wayland; others see lag spikes under GPU or memory pressure.

Wayland vs X11: Design & Ecosystem

  • Wayland praised for:
    • Eliminating tearing by design and enabling modern features (HDR, VRR, better security, simpler core).
    • Being extensible via protocols rather than a single monolith.
  • Criticisms focus on:
    • Fragmentation: many compositors, non‑uniform support for window management, input, color calibration, accessibility, screen readers, and advanced input workflows (e.g., multi‑host keyboard/mouse, stream decks).
    • Regressions vs X11’s long‑mature feature set, especially for visually impaired users and power‑user tooling.
    • The “protocol not implementation” stance being seen as dodging responsibility for user‑visible problems.

Maturity, Politics, and Backwards Compatibility

  • Long meta‑discussion: X11 is old, messy, but battle‑tested; Wayland is younger, still missing polish and some protocols.
  • Some argue X11 could have been secured and modernized instead of replaced; others say its architecture and codebase were effectively unfixable, and most ex‑X developers have moved on to Wayland.
  • Several users report better responsiveness and less tearing on Wayland; others find it buggier or unusable with certain GPUs or workflows.

Related Tools & Ideas

  • Mention of Typometer, Perfetto, custom hardware rigs, and other approaches to measuring UI and terminal latency.
  • General agreement that more systematic, cross‑compositor measurements are needed to pinpoint where latency is introduced and how to fix it.