Quantifying Linux Input Latency: Microcontroller Benchmarks Reveal X11 vs. Wayland Deltas, VRR Performance, and XWayland Overhead

Real-world latency testing using a custom RP2040-based photodiode measurement rig reveals that native Wayland introduces less than 0.25 ms of input lag compared to X11. However, running games through XWayland adds a massive 3.13 ms penalty, while variable refresh rate implementations significantly stabilize frame pacing.

Hardware-Based Latency Measurement Stack

To objectively evaluate the end-to-end click-to-photon latency of the Linux desktop graphics stack, a custom hardware-based testing rig was designed. The system leverages an Adafruit QT Py RP2040 configured as a USB HID mouse operating at a 1000 Hz polling rate. Upon issuing a click command, the microcontroller captures raw analog signals from a BPW34 photodiode via a transimpedance amplifier on a perfboard.

The RP2040 samples the photodiode every 24 microseconds, streaming 12,000 samples per click over serial to the host PC in CSV format. A host-side analysis tool establishes a baseline signal level for each click, determining the precise arrival of the frame by finding the first sample that deviates from the baseline. This setup eliminates software-induced polling variance, providing sub-millisecond precision for end-to-end system latency evaluations.

Software Environment and Execution Context

Testing was conducted on CachyOS running Linux Kernel 7.1.3-2-cachyos, paired with an NVIDIA GeForce RTX 4070 SUPER using driver version 610.43.03-1. The hardware configuration also included a Ryzen 7 5800X3D CPU and an MSI MAG 272QP QD-OLED monitor operating at a native 2560x1440 resolution and 500 Hz refresh rate. The software stack consisted of KDE Plasma 6.7.2-1.1, xorg-server 21.1.24-1.1, and Proton-CachyOS-Native.

To ensure direct scanout (Flip mode) and bypass compositor-induced blitting latency on Wayland, the KWin Debug Console was utilized to verify the absence of compositing borders when the test game, Diabotical (DX11 running under Proton/DXVK 3.0), was focused in fullscreen. Test cases were run across static, CPU-bound in-game scenes with low settings to guarantee zero frame rate fluctuations, utilizing 300 clicks per configuration to establish statistical distributions.

Native Wayland vs. X11 and the XWayland Penalty

The empirical data disproves the common assumption that native Wayland introduces severe input latency compared to X11. Across all comparable scenarios, native Wayland trailed X11 by a negligible delta ranging from only 0.14 ms to 0.22 ms. In a plain configuration without frame pacing or variable refresh rates, X11 achieved a median click-to-photon latency of 4.79 ms, while native Wayland recorded 4.93 ms.

While native Wayland performance is highly competitive, the translation layer tells a different story. Running the identical test case through XWayland instead of native Wayland (PROTON_ENABLE_WAYLAND=1 disabled) introduced a substantial performance penalty. XWayland yielded a median latency of 8.06 ms compared to native Wayland’s 4.93 ms, representing an additional 3.13 ms overhead that accounts for the perceived lag reported by users running non-native clients.

VRR and DXVK Low-Latency Frame Pacing

Enabling Variable Refresh Rate (VRR) yielded the most pronounced latency reductions and improved consistency across all configurations. VRR decreased median latency by 0.26 ms to 0.45 ms. Under native Wayland with the dxvk-low-latency fork active, enabling VRR dropped median latency from 4.83 ms to 4.38 ms. Beyond raw speed, VRR compressed the statistical distribution of frame delivery, reducing the p95-p5 spread from 2.6–3.0 ms down to 2.1–2.2 ms by scanning out frames as soon as they were rendered instead of waiting for fixed intervals.

The dxvk-low-latency frame pacer, recently upstreamed to Proton-CachyOS via the PROTON_DXVK_LOWLATENCY=1 environment variable, also demonstrated measurable benefits. In CPU-bound, capped test scenarios, the low-latency fork shaved off roughly 0.18 ms of latency. However, in uncapped, highly fluctuating test runs, the custom frame pacer delivered its most significant advantage, yielding an overall latency reduction of 0.84 ms by actively preventing render-queue buildup.