Linux input latency: X11 vs Wayland measured with custom hardware

Key Takeaways

• Custom hardware testing reveals measurable differences between X11 and Wayland input latency
• DXVK low-latency fork now integrated into official proton-cachyos package
• Native Wayland outperforms XWayland; direct scanout mode eliminates compositor overhead

Marco Nett, a developer and Linux gaming enthusiast, spent two years building custom hardware to answer a question that plagues competitive gamers on Linux: does Wayland actually have worse input latency than X11, or is it placebo? His open-source testing rig, now available on GitHub, measures end-to-end system latency from mouse click to screen response. The results challenge some common assumptions.

Why existing advice on Linux gaming optimization felt like guesswork

The internet is saturated with tips for optimizing Linux gaming: magic environment variables, gamescope, gamemode, specialized DXVK forks. Nett played competitive FPS games where milliseconds matter, but he had no way to verify whether these tweaks actually reduced latency or just felt different. So he built his own testing apparatus.

The device straps a light sensor onto a monitor and connects via USB to simulate mouse clicks. On each click, it measures the time between the input and the moment the sensor detects a brightness change on screen. This captures true end-to-end latency, including the display stack, compositor, and game engine.

Nett based his design on existing open-source latency testing devices like OSLTT, m2p-latency, and Open-Source-LDAT, learning microcontroller programming, soldering, transimpedance amplifiers, and KiCad along the way. The full hardware schematics, firmware, and raw test data are public.

What the tests actually measured

Nett tested Diabotical, a DirectX 11 game running through Heroic with Proton. He used a hidden command to produce large brightness changes on click, creating measurable light deltas for the sensor. Every capped test case held stable frame rates, and the game remained CPU-bound throughout testing. The data produced bell-shaped distributions roughly 2-3ms wide with no wild outliers.

He ran native Wayland tests using PROTON_ENABLE_WAYLAND=1, knowing from prior experience that XWayland introduces lag. For comparison, he added XWayland test cases with VRR disabled. Only one display was connected, using the default CachyOS kernel scheduler.

Direct scanout vs compositing: the hidden variable

One critical factor Nett identified: flip mode versus blit mode on Wayland. There is no setting for this. The compositor decides automatically whether to composite a frame or use direct scanout. To verify the game runs in flip mode, he used KWin Debug Console's showcompositing option. If no red border appears around the fullscreen game, direct scanout is active.

This matters because compositing adds latency. A game running in direct scanout bypasses the compositor entirely, while blit mode means every frame gets composited before display.

DXVK low-latency fork: what it does and why it matters

The DXVK low-latency fork, maintained by a developer called netborg, implements a frame pacer designed to absorb frame time fluctuations and prevent render-queue buildup. This fork recently got integrated into the official proton-cachyos package, enabled via the environment variable PROTON_DXVK_LOWLATENCY=1.

Nett notes that his static in-game test scene produced purely CPU-bound scenarios with no frame time fluctuations. This does not reflect real gaming sessions where other processes compete for resources and in-game events cause spikes. To show the pacer working, he added uncapped test cases where frame times naturally vary.

His optimized dxvk.conf for low-latency VRR testing:

dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
d3d11.cachedDynamicResources = "c"

The X11 vs Wayland debate: what searching actually shows

Searching for X11 versus Wayland input latency surfaces countless complaints that Wayland "feels off." Many competitive players stick with X11 specifically because of perceived latency issues. Variable Refresh Rate support, called G-Sync, FreeSync, or VRR depending on vendor, adds another variable. Some claim VRR improves perceived smoothness; others say it introduces lag.

Nett's testing method provides actual numbers instead of subjective impressions. The XWayland test cases he added show measurable differences from native Wayland, confirming that the translation layer adds overhead. Native Wayland with direct scanout appears to be the optimal configuration.

Why this matters beyond gaming

Input latency is not just a gaming metric. Any application requiring low-latency input, from music production software to trading terminals, cares about the same stack. Wayland is becoming the default display protocol for major Linux distributions. KDE Plasma 6 and GNOME both push Wayland as primary. Understanding its actual latency characteristics, measured rather than assumed, affects technical decisions across industries.

The transition from X11 to Wayland has been happening for over a decade, but practical tooling for measuring the difference has lagged. Nett's contribution is not just the test results but the methodology and open hardware design that others can replicate.

Frequently Asked Questions

Does Wayland have higher input latency than X11?

Not necessarily. Native Wayland with direct scanout can match or beat X11, but XWayland introduces measurable overhead. The compositor behavior and whether direct scanout is active matters more than the protocol choice alone.

How do you enable DXVK low-latency mode?

Set the environment variable PROTON_DXVK_LOWLATENCY=1 when launching games through Proton. This is now integrated into the official proton-cachyos package.

How can I check if my game is using direct scanout on Wayland?

Open KWin Debug Console, enable showcompositing in the Effects tab, then run your game fullscreen. If there is no red border visible, the game is using direct scanout and bypassing the compositor.

What hardware is needed to build this latency testing device?

The project uses a microcontroller, light sensor, and USB connection to simulate inputs. Full schematics and firmware are available on the author's GitHub. The design draws from OSLTT, m2p-latency, and Open-Source-LDAT projects.

Source: Hacker News: Best