Click-to-Photon Rigs Are Ending the Wayland Lag Debate

For as long as Wayland has existed as a viable daily driver, there's been a persistent rumor running through gaming forums: it feels laggier than X11. Nobody could prove it. Nobody could disprove it either. The usual evidence was a forum post, a shaky phone video, and a lot of confident vibes. That's finally changing, because a handful of developers got tired of vibes and built actual instruments to measure it.

Three separate projects, using three different measurement rigs, on three different hardware combinations, have now published click-to-photon latency data comparing X11, Wayland, VRR, and DXVK's low-latency frame pacer. They don't fully agree with each other, which is itself the most useful finding here. The picture that emerges is more interesting than "Wayland bad": the real story is that most of what gamers attribute to display-server religion is actually frame pacing, compositor quirks, and background processes nobody thought to blame.

Why nobody trusted the old evidence

An FPS counter tells you how fast frames are produced. It tells you nothing about how long it takes for a mouse click to physically change a pixel on your screen, which is the number that actually determines whether a game "feels" responsive. That end-to-end number, click-to-photon latency, requires a sensor pointed at the monitor and a way to timestamp the input event with precision.

Developer Marco Nett built one from scratch: an Adafruit QT Py RP2040 acting as a 1000Hz USB HID mouse, paired with a BPW34 photodiode and a transimpedance amplifier on perfboard, strapped to a monitor with an elastic band. On click, it fires the HID event and immediately starts sampling the photodiode every ~24 microseconds, streaming 12,000 samples per click back over serial. A baseline is established per click, and the first sample that deviates from it marks the moment light actually changed. That's genuinely fine-grained instrumentation, on par with commercial tools like NVIDIA's LDAT or the open OSLTT devices Nett based parts of the design on, and it's all released with hardware, firmware and analysis code.

A second build, documented at farnoy.dev, used a Teensy microcontroller running a modified Open Source LDAT sketch across a desktop and laptop, both Zen 4 with Ada-generation RTX cards, against an LG C1 at 120Hz. A third, much scrappier approach from the blog Mort's Ramblings skipped custom hardware entirely and just filmed a mouse cursor at 240fps on an iPhone, counting frames between physical movement and cursor movement by hand.

The gap in rigor between the phone-camera method and the photodiode rigs is worth sitting with. At 240fps you get one frame roughly every 4.17ms, which is barely finer than a single refresh cycle on a 144Hz screen. A photodiode sampling every 24 microseconds resolves latency differences two orders of magnitude smaller. And yet the cruder method still produced a clean, repeatable signal, which tells you the underlying effect isn't subtle.

X11 vs Wayland: real, small, and shrinking

Mort's camera test, run on GNOME 47 on Fedora Workstation 41 with an AMD Radeon RX 7900XT, found GNOME X11 cursor movement averaging 16.7ms of latency across 16 trials, versus 23.2ms on GNOME Wayland, a difference of roughly 6.5ms, or close to one refresh cycle on that display. The author is upfront that this is cursor-specific: GNOME's compositor handles the cursor plane very differently from application content, and the result may say nothing about how a fullscreen game behaves.

That caveat turns out to matter a lot. Farnoy's testing, done on KDE Plasma with an NVIDIA setup, dropped X11 comparisons entirely, partly because KDE has been signaling it will retire the X11 session, and focused instead on tuning within Wayland: native "wine_wayland" Proton sessions versus running games through XWayland. Their conclusion, in their own words, was to "prioritize wine_wayland, use late FPS limiting, VKD3D_SWAPCHAIN_LATENCY_FRAMES=1 in DX12 games, and VRR if the game can't hit a stable target or has bad frame pacing." That's a meaningfully different conclusion than "switch to X11 for competitive play," which is still the default advice on forums like CachyOS's and Blur Busters'.

So the honest read: there is a measurable X11-vs-Wayland gap on at least one desktop environment and GPU vendor combination, but it looks compositor-specific (GNOME's cursor path) rather than a fundamental protocol tax, and running native Wayland through a modern Proton build appears to close most of the gap that matters for actual gameplay. The forum consensus that Wayland is categorically worse is outdated, or at minimum, overgeneralized from GNOME's cursor handling to gaming performance as a whole.

The real culprits were never the display server

The most useful finding across this round of testing has nothing to do with X11 or Wayland at all. Farnoy discovered their desktop machine was consistently slower than an near-identical laptop running the same NixOS config, and traced it, after a lot of dead ends, to having a Zed editor window open in the background. An idle, unrelated app was adding latency system-wide, though notably not inside fullscreen games. They also found that opening KDE's Konsole terminal to mark test runs created large wl_shm surfaces that took long enough to copy over PCIe that the compositor's timing heuristics got permanently pessimistic for the rest of the session.

On the display side, testing an LG C1 TV turned up its own gremlins: Black Frame Insertion added a full frame of latency despite there being no technical reason it couldn't be done with a lagless rolling scan, HDR added a small but measurable hit, and Linux plus NVIDIA apparently doesn't support HDMI Auto Low Latency Mode at all, a feature farnoy remembered fighting on Windows with a Radeon GPU by faking an EDID.

None of that is a display-server problem. It's a reminder that the actual latency budget in a modern desktop is spread across the compositor, the window manager's idle behavior, background GPU-accelerated apps, the cable, and the TV's own processing pipeline, long before X11 versus Wayland enters the picture.

What this means if you actually build responsive software

This isn't only a gamer's concern. Anyone shipping latency-sensitive UI on Linux, remote desktop clients, VR compositors, kiosk touchscreens, pro-audio or trading front ends, has the same measurement problem: your framework's FPS counter or xdotool timestamp tells you nothing about photon-to-photon truth. A few concrete takeaways:

• Instrument before you optimize. A DIY rig is genuinely cheap: an RP2040 board, a photodiode, an op-amp, and some firmware gets you to microsecond-level click-to-photon measurement. If you're making latency claims in a support ticket or a design doc, this is the only way to know if a change actually helped or if you're chasing placebo.
• Test the actual levers, not folklore. The concrete knobs worth checking on a Proton/Wine stack: PROTON_ENABLE_WAYLAND=1 for native Wayland instead of XWayland, PROTON_DXVK_LOWLATENCY=1 to enable netborg's dxvk-low-latency frame pacer (now integrated into proton-cachyos), VKD3D_SWAPCHAIN_LATENCY_FRAMES=1 for DX12 titles, and a late-method FPS limiter (MangoHud supports this) rather than an early one. VRR helps most when the workload can't hold a stable frame rate or has pacing jitter, it's not a magic latency eraser on its own.
• The DXVK frame pacer's benefit is conditional. Nett's testing found that in a static, CPU-bound scene there was no frame-time fluctuation for the pacer to absorb, so it showed little advantage there; its actual job is preventing render-queue buildup and smoothing jitter under real, variable load, which a synthetic static benchmark won't reproduce. Don't judge a frame pacer by a steady-state benchmark.
• Confirm flip mode, don't assume it. On Wayland there's no user-facing toggle; whether a game gets direct scanout or gets composited is decided by the compositor. KWin's debug console has a showcompositing overlay that puts a red border around anything being composited rather than flipped, which is the only reliable way to verify you're actually in the low-latency path.
• Audit your background apps. Before blaming the display server, check what else is running. An idle Electron-based editor measurably degrading system-wide latency is not a hypothetical, it happened to someone running a purpose-built test rig specifically to rule out exactly that kind of noise.

The verdict

The X11-versus-Wayland input-lag war isn't nonsense, but it's also not the fundamental architecture problem the forums insist it is. The measured gap is real on at least one compositor and appears to live mostly in cursor handling, not application rendering, and a properly configured native Wayland session with the right frame-pacing env vars closes most of the practical difference for actual games. Given that KDE is already moving to retire X11 sessions, optimizing your workflow around X11 forever is a bet against where the ecosystem is headed anyway.

The bigger win here isn't a verdict on any one display server. It's that click-to-photon instrumentation, cheap enough now for a hobbyist to build in a weekend, has turned a decade of anecdote into something you can actually falsify. If responsiveness matters to your users, that's the standard to hold your own stack to, not a forum thread.