Measuring Input Latency on Linux: X11 vs Wayland, VRR, and DXVK Low‑Latency
Measuring Input Latency on Linux: X11 vs Wayland, VRR, and DXVK Low‑Latency
TL;DR
- On a high‑refresh (500 Hz) Linux gaming rig, native X11 is only 0.14‑0.22 ms faster than native Wayland.
- Enabling Variable Refresh Rate (VRR) reduces latency by 0.26‑0.45 ms and narrows jitter.
- The DXVK low‑latency fork saves 0.10‑0.29 ms in capped scenarios and 0.84 ms when the frame rate is uncapped.
- Running games through XWayland adds ~3.13 ms, the largest single penalty measured.
- Overall, applying all optimisations (X11 + VRR + DXVK low‑latency) lowers median end‑to‑end latency by 0.72 ms compared to a default plain Wayland setup.
Measuring End‑to‑End Input Latency
The author built a click‑to‑photon device using an Adafruit QT Py RP2040 that acts as a USB HID mouse (1 kHz polling). When a click is sent, the microcontroller samples a photodiode at ~24 µs intervals, streaming 12 000 samples per click to the host. A host‑side script establishes a baseline brightness and detects the first sample that deviates beyond a threshold, yielding the time between click and screen‑pixel change.
"Because the time it takes to collect 12k samples is fixed, it can now calculate the time between sending the click and detecting a brightness change on the screen." – author
This method captures peripheral latency, PC processing latency, and display latency in a single measurement.
Test Matrix
| Variable | Options |
|---|---|
| Display server | X11 (native), Wayland (native), XWayland (Wayland + X11 compatibility) |
| VRR | Off, On |
| DXVK low‑latency | Off, On |
| Frame‑rate cap | Capped at refresh (500 Hz) or uncapped (GPU‑bound) |
All tests used the same hardware and software stack:
- CPU: AMD Ryzen 7 5800X3D
- GPU: NVIDIA RTX 4070 SUPER, driver 610.43.03
- Display: MSI MAG 272QP QD‑OLED, 2560×1440 @ 500 Hz
- OS: CachyOS 7.1.3 kernel, KDE Plasma 6.7.2, Xorg 21.1.24, Proton‑cachyos 11.0, DXVK 3.0
- Game: Diabotical (DirectX 11) via Heroic + Proton, static scene, 100 clicks per run, three runs per configuration.
Flip mode (direct scanout) was verified on both X11 and Wayland; VRR was enabled via NVIDIA settings (X11) or KDE settings (Wayland).
Results Overview
All latency values are median click‑to‑photon times (ms). Each case used 300 clicks (3 × 100) and produced a bell‑shaped distribution with a 2‑3 ms inter‑quartile spread.
1. X11 vs. Native Wayland
| Config | X11 (ms) | Wayland (ms) | Δ (Wayland‑X11) |
|---|---|---|---|
| Low‑latency + VRR | 4.21 | 4.38 | +0.17 |
| Low‑latency only | 4.64 | 4.83 | +0.19 |
| VRR only | 4.45 | 4.67 | +0.22 |
| Plain (no VRR, no low‑latency) | 4.79 | 4.93 | +0.14 |
Conclusion: X11 is consistently a few‑tenths of a millisecond faster, but the gap is far too small to explain the common perception that Wayland feels sluggish.
2. Impact of Variable Refresh Rate (VRR)
| Config (X11) | VRR off (ms) | VRR on (ms) | Δ |
|---|---|---|---|
| Low‑latency | 4.64 | 4.21 | -0.43 |
| Plain | 4.79 | 4.45 | -0.34 |
| (Wayland) Low‑latency | 4.83 | 4.38 | -0.45 |
| (Wayland) Plain | 4.93 | 4.67 | -0.26 |
Conclusion: Enabling VRR yields the largest single latency reduction (≈0.3‑0.45 ms) and also tightens jitter (p95‑p5 spread shrinks from ~2.6‑3.0 ms to ~2.1‑2.2 ms).
3. DXVK Low‑Latency Fork (capped tests)
| Config | DXVK low‑latency off (ms) | DXVK low‑latency on (ms) | Δ |
|---|---|---|---|
| X11 + VRR | 4.45 | 4.21 | -0.24 |
| X11 plain | 4.79 | 4.64 | -0.15 |
| Wayland + VRR | 4.67 | 4.38 | -0.29 |
| Wayland plain | 4.93 | 4.83 | -0.10 |
Conclusion: The fork improves latency by roughly the same magnitude as the X11‑vs‑Wayland gap (≈0.1‑0.3 ms) when the frame rate is capped.
4. Uncapped Scenario (GPU‑bound)
| Metric | Low‑latency off | Low‑latency on |
|---|---|---|
| Median latency (ms) | 5.27 | 4.43 |
| FPS | 715 | 670 |
| GPU utilization | ~100 % | 95‑97 % |
Conclusion: When the GPU runs at full throttle, the low‑latency DXVK pacer reduces end‑to‑end latency by 0.84 ms at the cost of ~45 FPS, while keeping the GPU from hitting 100 % utilization.
5. XWayland Penalty
| Config | Native Wayland (ms) | XWayland (ms) | Δ |
|---|---|---|---|
| Low‑latency | 4.83 | 5.95 | +1.12 |
| Plain | 4.93 | 8.06 | +3.13 |
Conclusion: Running a game through XWayland adds 3.13 ms of latency in the plain case—more than the sum of all other measured effects. Adding DXVK low‑latency to XWayland recovers 2.11 ms, the biggest single gain observed.
Synthesis of Findings
- X11 vs. Wayland: The raw difference is sub‑millisecond; both are essentially comparable for competitive gaming when using native pathways.
- VRR: Provides the most consistent latency reduction and jitter improvement across all display‑server configurations.
- DXVK low‑latency: Offers modest gains in capped scenarios and a noticeable advantage when the GPU is saturated.
- XWayland: Should be avoided for latency‑critical titles; its overhead dwarfs the other optimisations.
- Combined effect: Applying all three optimisations (X11 + VRR + DXVK low‑latency) lowers median latency by 0.72 ms compared to a default plain Wayland setup.
While 0.7 ms may seem minor, at 500 Hz each frame lasts only 2 ms, so a 0.7 ms reduction represents a 35 % improvement in the fraction of a frame that contributes to perceived input lag. Moreover, VRR’s jitter reduction can make gameplay feel smoother even when raw numbers are close.
Community Reactions
"One thing that's lovely about Linux is this kind of analysis is not only possible, but meaningful. These results will get reported back to the graphics software authors and the ecosystem will improve." – NelsonMinar
"He seems confused at the end why people think Wayland is so slow, but don’t you think it’s because of his XWayland result?" – cgyvbunji
"There's no such thing as 'Wayland input latency'. The post is measuring Xorg vs. KWin (and also XWayland)." – seba_dos1
"The XWayland result is 3 ms slower, which at this refresh rate makes me wonder if it was one frame behind. Running the tests at 120 Hz or 60 Hz might be more interesting." – Aurornis
"Avoid XWayland. It added 3.13 ms of latency, more than all other effects combined." – haunter
These comments reinforce the article’s key takeaways: the perceived Wayland lag is largely an XWayland artifact, and the community values concrete measurements to guide future compositor and driver work.
Practical Recommendations for Linux Gamers
- Prefer native Wayland or X11 for competitive titles; both deliver comparable latency.
- Enable VRR (FreeSync/G‑Sync) on high‑refresh displays to shave 0.3‑0.45 ms and reduce jitter.
- Use the DXVK low‑latency fork (or Proton’s
PROTON_DXVK_LOWLATENCY=1) especially when the GPU is often saturated. - Avoid XWayland unless forced by a game’s launcher; consider using
PROTON_ENABLE_WAYLAND=1or a native Wayland build. - Monitor GPU utilization; if it stays near 100 %, the low‑latency pacer can improve responsiveness at a modest FPS cost.
Related Work
- David Ramiro’s m2p‑latency study reached similar conclusions: native Wayland ≈ X11, XWayland roughly doubles latency.
- Farnoy’s Open‑Source‑LDAT tests also warned against XWayland.
- Themaister’s VK_EXT_present_timing approach measures PC‑only latency, complementing the end‑to‑end method used here.
Closing Thoughts
The author’s click‑to‑photon rig demonstrates that precise, hardware‑based latency measurement is feasible on Linux and yields actionable data. The myth that Wayland is inherently slower is debunked; the real culprit is XWayland. Enabling VRR and the DXVK low‑latency pacer provides measurable benefits, especially on ultra‑high‑refresh panels where every tenth of a millisecond counts.