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

When Linux gamers chase lower input latency, they often rely on anecdote rather than hard data. Marco Nett built a DIY rig that combines an Adafruit QT Py RP2040 acting as a 1000 Hz USB HID mouse with a photodiode that samples every ~24 µs. By streaming 12,000 samples per click to a CSV, the rig captures the full end‑to‑end latency chain from click to screen change. The measurements compare X11, Wayland, variable‑refresh‑rate (VRR) modes, and DXVK‑based DirectX‑to‑Vulkan translation, giving developers concrete numbers to back performance claims. Understanding these differences matters for anyone tuning Linux for competitive gaming or low‑latency UI work.

What happened

The rig uses a QT Py RP2040 to generate mouse clicks at a 1000 Hz polling rate. Immediately after each click, the microcontroller samples the attached photodiode at ~24 µs intervals, producing 12,000 samples per click that are logged to a CSV file for analysis. Tests were run on a 144.99 Hz 4K IPS monitor under native X11, native Wayland, with VRR enabled, and with DXVK translating DirectX calls to Vulkan. Across multiple runs, the X11 configuration yielded the smallest measured latency, typically a few milliseconds lower than Wayland. Enabling VRR added a small, consistent increase, while using DXVK introduced additional latency comparable to the VRR overhead. The data was corroborated by a secondary video‑based method that captured cursor movement at 240 FPS, confirming the order of magnitude of the differences.

Why it matters

Input latency directly impacts competitive gaming, where a few milliseconds can decide a match. Developers optimizing Linux graphics stacks need quantitative evidence to prioritize work on X11 compatibility layers, Wayland compositors, or DXVK improvements. System integrators and power users also benefit: knowing the latency cost of VRR helps decide whether the smoother visual experience outweighs the slight input delay.

How to think about it

Start by defining the latency budget for your target use case—gaming typically demands sub‑10 ms end‑to‑end latency. Replicate the DIY rig or use an existing open‑source device, then run baseline measurements on X11 before switching to Wayland. Record both raw click‑to‑light times and the visual cursor lag captured with a high‑frame‑rate camera. Compare the numbers against your budget; if VRR or DXVK push you over, consider disabling them for latency‑critical sessions. Finally, treat the measurements as a regression suite: any driver or compositor update should be re‑tested to catch inadvertent latency regressions.

FAQ