Click-to-Photon on Linux: X11 vs Wayland, VRR, and DXVK low-latency

The one experiment that made “input lag” finally measurable

For a while after switching to Linux gaming, “lower latency” felt like a religion. People would point to settings, forks, environment variables, kernel schedulers, and compositor tricks—then describe how their game felt snappier. And maybe it was. But the part that never sat right was the lack of a reliable number.

What you really want is something like click-to-photon testing: a way to measure the time from your mouse action to the first visible change on the display. Not a benchmark FPS number. Not “does it feel better.” An end-to-end latency you can compare across system tweaks.

This post walks through an approach to measure that pipeline on Linux, then uses it to reason about three hot topics that affect responsiveness in modern games:

• X11 vs Wayland (and the compositor’s role)
• Variable Refresh Rate (VRR) behavior
• DXVK low-latency frame pacing (especially in Proton-CachyOS)

The fun part? The method is hardware-backed, so you can stop arguing and start observing.

What “input latency” really includes

Input latency is not one single thing. Your “click” becomes internal events, then it becomes frames, then it becomes scanout, then it becomes light on the panel.

A helpful mental model is the pipeline from click to photons:

1. Peripheral latency: the time between your mouse click and the PC receiving input (USB polling and device firmware matter).
2. CPU/render queue latency: how long it takes the game and CPU-side work to schedule a frame.
3. GPU/render latency: how long the GPU needs to render that frame.
4. Compositing + scanout latency:
   - Compositing means the compositor (desktop display server) may blend layers into a final buffer.
   - Scanout means the display hardware reads the final buffer and pushes it out line-by-line to the panel.
5. Display latency: the panel’s response and pixel processing time.

When someone says “Wayland is lower latency” or “VRR fixes it,” they’re usually talking about one or more stages in that chain.

A click-to-photon measurement lets you observe the entire pipeline at once.

The device: turning a mouse click into timestamps

The core idea is straightforward: strap a light sensor to the monitor, then simulate repeated “mouse clicks” with a USB HID device, and measure when the screen brightness change becomes detectable.

The setup described below uses a small custom click-to-photon device built around:

• An RP2040 microcontroller (a small, fast microcomputer) acting as a USB HID mouse.
• A photodiode (a light sensor that turns light changes into an electrical signal).
• A transimpedance amplifier, which converts the photodiode’s tiny current changes into a readable voltage.
• A tiny enclosure so the sensor can reliably “look” at the same part of the screen.

Once a synthetic click is sent, the firmware starts sampling photodiode values at a fixed interval (about 24 microseconds between samples in the project). The data is streamed back to the host PC, where a script:

• Builds a baseline noise level per click.
• Finds the first sample that deviates enough to count as “the screen changed.”
• Computes the time difference from click send → screen change detection.

That’s the latency number you can compare across OS display server modes, VRR settings, and DXVK variants.

There’s also a broader ecosystem of similar open source latency testers, such as OSLTT, which documents an open source device and companion desktop software for latency measurements. (github.com)

The test variables: X11 vs Wayland, VRR on/off, and DXVK low-latency

To test responsiveness, you want to isolate variables. The experiment targets three major switches.

1) Display server: X11 vs native Wayland

X11 and Wayland are both “display servers,” meaning they sit between the game and the graphics stack and decide how frames become pixels.

• With X11, the traditional pipeline often involves an Xorg server and more explicit window-system behavior.
• With Wayland, the compositor is central: it can sometimes bypass extra work for fullscreen windows (direct scanout / flip-like behavior).

On the Wayland side, the ability to present buffers directly to scanout (bypassing extra compositing steps) is a major reason Wayland can feel different—good or bad depending on driver/compositor behavior. (wayland.freedesktop.org)

A practical trick in KDE Plasma is verifying whether fullscreen rendering is using direct scanout vs compositing. In KDE, developers often discuss using the KWin debug console and enabling the “showcompositing” effect to visualize compositing behavior (e.g., a red compositing indicator). (bugs.kde.org)

2) VRR: on vs off

VRR (Variable Refresh Rate) means the display refresh timing changes to follow the GPU’s frame production, rather than forcing a constant 60/120/240 Hz cadence.

In theory, VRR can reduce visible stutter and cut down the pain caused by frames arriving slightly early or late.

In practice, VRR can also interact with frame pacing: if the frame limiter or presentation logic is mismatched, you can end up with extra buffering or “v-sync-like” wait behavior.

That’s why VRR isn’t a single checkbox. It needs to be paired with how the rendering backend schedules frames.

3) DXVK low-latency: “frame pacer” rather than raw FPS

Many Linux games run via Proton, and DirectX-on-Linux typically routes through DXVK, which translates Direct3D calls to Vulkan.

Within DXVK, frame pacing choices affect latency. A “frame pacer” is logic that decides when each frame is allowed to start and when it’s presented.

The low-latency fork used in this workflow (often referenced as dxvk-low-latency) focuses on improving responsiveness and input lag via improved frame pacing and latency stability over time. It’s activated in Proton-CachyOS with the environment variable: PROTON_DXVK_LOWLATENCY=1. (git.hubp.de)

It also supports VRR-aware pacing modes and config options like dxvk.framePace (for example, VRR-enhanced pacing variants that try to avoid additional v-sync buffering latency). (git.hubp.de)

In other words: the goal isn’t “uncap FPS.” The goal is to prevent render-queue buildup and reduce latency variance frame-to-frame.

Why these combinations can produce surprising results

It’s tempting to believe the lowest latency configuration will win every time. Real systems are messier.

Here’s the core conflict you keep running into:

• X11 and Wayland affect where buffering happens and whether direct scanout can happen.
• VRR affects how presentation timing is aligned with display refresh.
• DXVK frame pacing determines how aggressively frames pile up while the GPU is busy.

A single extra frame in a queue can matter more than raw average FPS. Likewise, if compositing is enabled when you thought it was bypassed, that can add a measurable chunk of delay regardless of how fancy the GPU work is.

That’s why the click-to-photon method is valuable. It tells you whether your “best guess” actually shortened the pipeline.

A practical way to interpret the results

Once you collect measurements for each scenario (X11 vs Wayland, VRR on/off, low-latency DXVK on/off), the main interpretation pattern looks like this:

1. If switching display servers changes the median latency noticeably, compositing/scanout behavior likely shifted.
2. If VRR changes both median and variance, the presentation timing and buffering behavior likely changed.
3. If DXVK low-latency reduces tail latency (the slower-outlier frames), it suggests the frame pacer is preventing render-queue buildup.

Those “tail” improvements are exactly why input latency in competitive games isn’t only about averages.

What makes this specific Proton setup relevant

This test workflow uses a Proton build provided by CachyOS.

For example, the package proton-cachyos-native is published with versioned builds (one example shown in the package repository is 1:11.0.20260602-3). (packages.cachyos.org)

The important takeaway isn’t the exact version number; it’s that DXVK low-latency in Proton-CachyOS is meant to be enabled via PROTON_DXVK_LOWLATENCY=1, and the rest of the pipeline assumptions (like frame pacing and present behavior) depend on that Proton/DXVK integration.

A small benchmark twist: CPU-bound scenes vs real gameplay

A static in-game scene can make comparisons easier because frame times fluctuate less.

But real gameplay mixes GPU load, CPU load, and OS background activity. That’s where the “frame pacer” story becomes more visible.

So a strong methodology often includes two kinds of test cases:

• Stable, CPU-bound scenarios to isolate display-server and presentation behavior.
• Scenarios that intentionally create frame-time fluctuations (for example, by uncapping FPS) so the pacer has something to correct.

This helps you see whether DXVK low-latency is truly preventing backlog during variability, instead of only looking good in a perfectly controlled scenario.

Conclusion: stop chasing vibes, measure the pipeline

X11 vs Wayland, VRR on/off, and DXVK low-latency all influence different stages of the click-to-photon chain. The confusing part is that each lever can “help” in one stage while “hurt” in another.

A hardware-backed measurement method turns that fog into a timeline you can compare: click send time, screen change detection, and therefore end-to-end latency.

Once you treat input latency as a system pipeline—not a single setting—you can finally tell which Linux gaming tweaks reduce latency for real, and which ones only rearrange theory.