Measuring Input Latency on Linux: X11 vs. Wayland, VRR, and DXVK

Original Article ↗ Hacker News Discussion ↗

Careful measurements of mouse‑click‑to‑pixel latency on Linux show native Wayland and X11 performing nearly identically, while XWayland (running X11 apps under Wayland) adds about 3–4 ms—enough to matter for competitive gamers but not most users. Commenters use this as a springboard to revisit long‑running grievances about the Wayland transition, including broken workflows, missing features like easy window positioning and X forwarding, and variability between compositors and GPU drivers (especially Nvidia). Others argue that modern Wayland setups, particularly with AMD GPUs and KDE or gaming compositors like gamescope, are now fast and stable, and that much of the bad reputation stems from early, immature deployments and XWayland-specific issues.

Overall reaction to the measurements

  • Many praise the article for rigorous, reproducible measurement of click‑to‑photon latency with custom hardware and careful control of variables.
  • Key numeric takeaway echoed repeatedly: native X11 and native Wayland are very close; XWayland adds roughly 3–4 ms and is consistently worse.
  • Several note this aligns with previous independent latency projects, which also found XWayland as the main outlier.

Perceived latency vs measured latency

  • Strong debate over whether 2–4 ms differences are perceptible:
    • Some argue this is far below human sensitivity for typical users and dwarfed by monitor refresh intervals, network ping, and game engine behavior.
    • Others (competitive FPS and rhythm‑game players, musicians) insist they can feel a few milliseconds and that it measurably affects performance, especially at high refresh rates.
  • Multiple people stress that at 60 Hz, “one extra frame” translates to tens of milliseconds, so protocol overhead that costs frames matters more on common displays than on a 500 Hz panel.

Wayland vs X11: ecosystem and transition

  • Many caution that the article only measures one Wayland compositor (KDE’s) plus XWayland on one GPU; other compositors can be better or worse.
  • Some argue that negative impressions of Wayland come from:
    • Older, less mature implementations.
    • Nvidia’s historical Wayland/XWayland issues (composition pipeline, software cursor).
    • Gnome/Mutter stalls and different mouse acceleration curves.
  • Others are critical of the Wayland transition:
    • Perceived as “forced” before feature parity (remote display, window positioning, embedding, screen sharing, X forwarding, etc.).
    • Large amounts of developer effort diverted to “adding Wayland support” instead of visible features.
    • Complaints about missing or fragmented protocols and DE‑specific extensions.
  • Counter‑arguments emphasize that:
    • X11 and Xorg are effectively end‑of‑life and heavily encumbered by legacy and security issues.
    • Developers are not obligated to keep maintaining X; it’s legitimate to move to a cleaner design.
    • Current Wayland setups (especially AMD + KDE or gamescope) are reported as stable and low‑latency by many users.

Related topics raised

  • Interest in:
    • Comparing Gnome, Hyprland, gamescope, and other compositors.
    • Testing at 60/120 Hz and with non‑3D desktop apps.
    • Windows and FreeBSD latency baselines on the same hardware.
  • Discussions touch on:
    • Gaming‑oriented distros (Bazzite, CachyOS, Nobara) and immutable desktops.
    • Game streaming stacks (Sunshine/Moonlight vs Steam streaming) under Wayland vs X11.
    • Broader frustration with desktop UX regressions and theming, separate from latency.