The X11 versus Wayland debate has been polluting Linux gaming forums for years, fueled by subjective impressions and very few concrete measurements. Marco Nett decided to build his own measurement setup to put an end to the guesswork. The results published in July 2026 are clear, backed by numbers, and contradict several widely held assumptions.
Measuring Linux Input Latency: the Method
Rather than relying on feel, Marco Nett designed a custom hardware setup. An Adafruit QT Py RP2040 microcontroller simulates mouse clicks at 1000 Hz, and a BPW34 photodiode detects brightness changes on screen. Everything connects via USB to the PC to calculate end-to-end latency, from click to photon.
The test game is Diabotical, a DirectX 11 title launched through Heroic with Proton. The hardware configuration is precise: AMD Ryzen 7 5800X3D, RTX 4070 SUPER, 500 Hz QD-OLED monitor. The software runs on CachyOS with the NVIDIA 610 driver and KDE Plasma 6.7.
Each scenario accumulates 300 clicks to produce statistically solid distributions. The methodology is reproducible and documented.
X11 vs Native Wayland: an Almost Imperceptible Difference
Linux input latency in native mode shows very close numbers between the two display servers.
| Configuration | X11 | Wayland | Difference |
|---|---|---|---|
| Plain | 4.79 ms | 4.93 ms | +0.14 ms |
| VRR | 4.45 ms | 4.67 ms | +0.22 ms |
| Low-latency | 4.64 ms | 4.83 ms | +0.19 ms |
| VRR + low-latency | 4.21 ms | 4.38 ms | +0.17 ms |
X11 wins in every scenario, but the gap never exceeds 0.22 ms. These results align with those of David Ramiro, who with his m2p-latency project reaches the same conclusion: native X11 and native Wayland are practically tied around 7 ms in his tests.
The perception that Wayland is significantly slower than X11 simply has no measurable basis in native mode.
XWayland: the Real Culprit
Things change drastically when an X11 application runs through XWayland under Wayland. Without dxvk-low-latency, XWayland adds 3.13 ms of latency compared to native Wayland (8.06 ms versus 4.93 ms). That is more than all other measured effects combined.
The entire distribution shifts, it is not just a few outlier frames pulling the average up. When XWayland is unavoidable, enabling dxvk-low-latency recovers 2.11 ms, which is the largest single gain observed in the entire study.
The conclusion is clear: avoiding XWayland is the absolute top priority for anyone who cares about latency on Linux.
VRR: the Most Impactful Lever
VRR (Variable Refresh Rate, G-Sync, FreeSync) has a bigger impact than the choice between native X11 and Wayland. Enabling it brings a gain of 0.26 to 0.45 ms depending on the configuration, which is more than double the native X11 / Wayland gap.
Beyond reducing median latency, VRR also flattens the distribution: the gap between the 5th and 95th percentile drops from 2.6 to 3.0 ms without VRR down to just 2.1 to 2.2 ms with VRR. Less jitter, more predictable frames. This is consistent with how VRR works: frames are sent to the display as soon as they are ready.
DXVK Low-Latency: Small Gain When Capped, Big Gain When Uncapped
The dxvk-low-latency fork, maintained by netborg and integrated into proton-cachyos, shows interesting results.
In capped mode (FPS limited to the refresh rate), the gain is modest but consistent:
- Between 0.10 and 0.29 ms depending on the configuration
- Comparable in magnitude to the native X11 / Wayland gap
In uncapped mode, the pacer reveals its real strength. Without dxvk-low-latency, latency climbs to 5.27 ms. With it, it drops to 4.43 ms, a gain of 0.84 ms. The trade-off is that FPS drops from 715 to 670, as the pacer keeps GPU utilization at 95 to 97% to avoid saturating the render queue.
The pacer’s main benefits show up in real-world scenarios where frame times fluctuate, not in a static scene with no bots.
A Complementary Approach: VK_EXT_present_timing
Themaister published on July 2, 2026 a different approach to measuring latency without external hardware. By injecting inputs via /dev/uinput and detecting image changes directly on the GPU through the Vulkan extension VK_EXT_present_timing, he isolates PC latency by excluding USB and display. It is a programmatic method useful for comparing software configurations in an automated way.
Key Takeaways
- XWayland is the real problem: +3.13 ms compared to native Wayland, more than all other factors combined. Enabling native Wayland mode in Heroic or Proton is the top priority.
- Native X11 and Wayland are nearly identical: the 0.14 to 0.22 ms gap does not justify staying on X11 for latency reasons.
- VRR delivers the biggest gain: 0.26 to 0.45 ms reduction, plus reduced jitter. On a compatible monitor, enabling it is more effective than the choice of display server.
- dxvk-low-latency is worth it: modest gain when capped, but significant in real uncapped usage and very useful when XWayland is unavoidable.
- These results are specific to this hardware: absolute numbers will vary by setup, but the relative trends should transfer.
If these measurements are useful for optimizing your Linux gaming setup or you are working on low-latency environments, feel free to discuss. Subscribe to the blog to stay up to date with future analyses.
Sources
- Marco Nett, “Measuring input latency on Linux: X11 vs Wayland, VRR, and DXVK” (July 13, 2026): https://marco-nett.de/blog/measuring-input-latency-on-linux-x11-vs-wayland-vrr-dxvk/
- Themaister, “My side quest measuring input latency with VK_EXT_present_timing” (July 2, 2026): https://themaister.net/blog/2026/07/02/my-side-quest-measuring-input-latency-with-vk_ext_present_timing/
- DXVK project (doitsujin/dxvk): https://github.com/doitsujin/dxvk
- David Ramiro, m2p-latency project: referenced in Marco Nett’s article