Linux input latency, measured: Wayland finally catches X11

What happened

A German developer, Marco Nett, wired up a high-speed camera, a modded mouse with an LED soldered across the left-click switch, and a frame-accurate capture pipeline to measure something Linux users have been arguing about since roughly 2013: how much input latency each part of the desktop graphics stack actually adds.

The test rig films the mouse LED and the monitor simultaneously at 1000fps, then counts frames between click and on-screen reaction. That gives a real end-to-end number — click-to-photon — instead of the synthetic in-engine measurements most benchmarks report. He ran it across X11 and Wayland on GNOME, KDE, and Hyprland; with and without Variable Refresh Rate; on native Linux games and on Windows games under DXVK; and across a 60Hz office panel and a 240Hz gaming panel.

The headline result: on a 240Hz display, Wayland sessions came in within 2-4ms of X11, and with VRR enabled Wayland was consistently *faster* than X11 by 5-10ms. On 60Hz the two were within measurement noise. Hyprland edged out GNOME and KDE by a small but repeatable margin. DXVK-translated D3D11 titles ran 3-8ms behind their native Vulkan counterparts — noticeable on paper, invisible in play for anything short of a Counter-Strike pro.

Why it matters

For most of the last decade, "Wayland has more input lag" was received wisdom on r/linux_gaming and in every HN thread about desktop protocols. It was true for a while — early wlroots and Mutter both did an extra composition pass that X11 skipped, and the numbers were bad enough that competitive players stuck with X. That's the version of the story most people are still carrying around.

Those numbers are now stale. The compositors caught up somewhere between 2023 and 2025 through direct scanout, tearing protocols, and adaptive-sync support, and this post is the first widely-shared measurement that actually shows it with a camera instead of a fps counter. The fact that the community had to wait for a hobbyist with a $200 slow-mo camera to settle it is its own indictment — GNOME, KDE, and the wlroots crew have all shipped latency improvements without ever publishing comparable end-to-end numbers themselves.

The VRR result is the genuinely interesting one. On X11, VRR support has been perpetually half-broken outside of full-screen exclusive mode. On Wayland, the adaptive-sync protocol lets the compositor coordinate presentation with the display's actual refresh, which means frames arrive sooner *and* more predictably. When you turn VRR on, Wayland doesn't just match X11 — it wins by roughly a full frame at 240Hz, because X11's VRR path is essentially unmaintained.

DXVK is the other surprise, in the other direction. The Proton crowd tends to talk about DXVK as if it were free — "often faster than native Windows!" is a common line, based on throughput benchmarks. Nett's numbers show the fps claim can be true while the *latency* claim isn't: translating D3D11 calls into Vulkan adds a small but real pipeline step, and 3-8ms of end-to-end input lag is exactly what you'd expect from an extra command-buffer hop. It doesn't matter for single-player games. It matters if you're on Linux specifically to shave latency in a shooter.

HN commenters largely accepted the methodology and pushed on edge cases: what about compositor bypass on X11, what about Gamescope, what about wired-vs-wireless mice at the input end. One thread convincingly argues the numbers would tighten further on Wayland once explicit sync lands universally and NVIDIA's driver stops needing the implicit-sync workaround.

What this means for your stack

If you're still on X11 specifically because of latency, that argument is dead. Switch to Wayland, turn on VRR, disable any triple-buffering your compositor lets you disable, and you'll be at or below your old X11 numbers on any modern GPU. The remaining reasons to stay on X11 are real — screen-sharing weirdness in some apps, specific NVIDIA workflows, muscle memory around window managers that don't have Wayland equivalents — but latency is no longer on the list.

If you daily-drive Hyprland or a wlroots compositor, the numbers say you're already on the fastest path available; the tearing and direct-scanout protocols do what they claim. If you're on GNOME or KDE, the gap to Hyprland is small enough (~2ms) that it's not worth a rice project unless you enjoy the process. What *is* worth doing: check whether your compositor's VRR toggle is actually on. Both Mutter and KWin ship it disabled by default on many distros.

For game developers targeting Linux, the DXVK finding argues for shipping a native Vulkan build when input latency is part of the pitch — competitive multiplayer, rhythm games, VR. For everything else, the translation cost is invisible and DXVK remains the right call. And for anyone building latency-sensitive desktop apps — trading terminals, DAWs, live-coding environments — Wayland + VRR is now a genuine perf win, not a compatibility tax you pay for a nicer protocol.

Looking ahead

The interesting next measurement is explicit sync at scale. NVIDIA's implicit-sync workaround has been the single biggest source of Wayland latency and jank on the ~70% of Linux gaming rigs running green cards, and the explicit-sync protocol finally landing across the stack should close most of the remaining gap. Expect a follow-up post — from Nett or someone with the same rig — sometime this fall showing NVIDIA + Wayland matching or beating AMD + X11 for the first time. When that lands, the last technical argument for X11 goes with it, and the migration question becomes purely one of app compatibility and habit.