Analyzing Input Lag on Linux: X11, Wayland, VRR, and DXVK

By Marco Nett

Two years ago, I migrated my primary gaming rig to Linux. The prevailing narrative was that Linux could actually outperform Windows in terms of raw FPS, frame pacing, and input responsiveness. Upon testing, the experience did indeed feel superior.

However, the community is rife with conflicting optimization tips:

"Wayland is terrible for input lag; stick to X11." "You must disable compositing (enable 'flip mode')." "Use a specialized low-latency DXVK fork." "Install a gaming-tuned kernel scheduler."

As a competitive FPS player, I care deeply about high frame rates, consistent frame times, and the lowest possible latency. While Linux offers a dizzying array of tweaks—from gamescope and gamemode to various "magic" environment variables—I found myself frustrated by the lack of empirical data. I wanted to know if these changes were actually improving performance or if I was just experiencing a placebo effect.

---

🛠️ The Measurement Hardware

To get objective data, I built a custom latency tester. The concept is straightforward: attach a light sensor to the monitor and connect it to the PC via USB to simulate a mouse click. The device measures the exact duration between the trigger of the click and the moment the sensor detects a change in screen brightness.

While projects like m2p-latency and Open-Source-LDAT exist now, I began by studying the OSLTT schematics. By the time I finished, I had integrated features from all three.

Hardware Components

• Microcontroller: Adafruit QT Py RP2040 (acting as a USB HID mouse @ 1000 Hz).
• Sensor: BPW34 photodiode.
• Circuitry: Transimpedance amplifier on a perfboard.
• Housing: A custom-designed enclosure with "wings" for elastic band mounting.

Learning Journey

Building this required me to brush up on several disciplines:

• Microcontroller programming
• Soldering techniques
• Arduino firmware development
• Transimpedance amplifier theory
• Basic KiCad design
• 3D enclosure modeling

How it Works

The process follows a strict timing loop:

1. The RP2040 sends a mouse click.
2. It immediately begins sampling the photodiode every $\approx 24\mu s$.
3. A total of 12,000 samples are streamed via serial to the host PC and saved as a .csv.

The host software then calculates the latency using the following logic: $\text{Latency} = (\text{Sample Index of Deviation} - \text{Baseline Index}) \times \text{Sample Interval}$

---

🧪 Testing Variables

I focused on four primary areas of interest:

1. Display Server: Comparing X11 against Native Wayland. (Many users claim Wayland "feels off" or laggy).
2. VRR: Testing Variable Refresh Rate (G-Sync/FreeSync) On vs. Off.
3. DXVK Forks: Comparing standard DXVK with the dxvk-low-latency fork (developed by netborg). This is now part of proton-cachyos and can be toggled via: PROTON_DXVK_LOWLATENCY=1
4. XWayland vs. Native: Since I used PROTON_ENABLE_WAYLAND=1 for most tests, I added a few XWayland cases (VRR off) for a baseline comparison.

Note on Frame Pacers: The dxvk-low-latency fork is designed to prevent render-queue buildup and smooth out frame time spikes. Since my tests used static scenes (CPU-bound), these fluctuations weren't naturally present, so I included "uncapped" test cases to specifically observe the pacer's behavior.

---

🖥️ Test Environment

Hardware Specifications

Software Stack

• OS: CachyOS (Kernel 7.1.3-2-cachyos)
• Driver: NVIDIA 610.43.03-1
• Desktop: KDE Plasma 6.7.2-1.1
• Xorg: 21.1.24-1.1
• Proton: proton-cachyos-native 1:11.0.20260602-3
• DXVK: Version 3.0

System Configuration

• Refresh Rate: 500 Hz.
• X11 Flip Mode: Enabled via nvidia-settings.
• Wayland Flip Mode: Verified via the KWin Debug Console.
  • Verification Method: Enable showcompositing in the Effects tab. If the game is fullscreen and focused and no red border appears, "Flip Mode" (direct scanout) is active.
• VRR: Enabled via nvidia-settings (X11 - requires reboot) or KDE Settings (Wayland - instant).

To ensure a fair comparison, I utilized a specific dxvk.conf tailored to each scenario:

# Example snippet of optimized dxvk.conf
dxvk.numBackBuffers = 2
dxvk.maxFrameLatency = 1