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

Linux 输入延迟测量：X11 对比 Wayland、VRR 和 DXVK

Two years ago, I switched to Linux on my gaming PC. People kept telling me that it could perform way better than Windows when it comes to FPS, frame pacing and input latency, and when I tried it out, it did feel a lot better. The internet is full of advice on optimizing Linux for gaming: Wayland has bad input lag, use X11; Disable compositing (“use flip mode”); Use a latency-optimized DXVK fork; Use a gaming-specific kernel scheduler, etc.

两年前，我将游戏电脑切换到了 Linux 系统。人们一直告诉我，在帧率（FPS）、帧生成时间（frame pacing）和输入延迟方面，它的表现可以远超 Windows。当我尝试之后，感觉确实好多了。互联网上充斥着关于优化 Linux 游戏性能的建议：有人说 Wayland 输入延迟高，建议使用 X11；有人建议禁用合成器（“使用翻转模式”）；有人建议使用针对延迟优化的 DXVK 分支；还有人建议使用游戏专用的内核调度器等等。

I play competitive FPS games, so low latency, consistent frame times and high FPS matter to me. On Linux, there are countless settings to tweak for this (magic env vars, gamescope, gamemode, even more DXVK forks, and so on). But it always bothered me that I did not have a reliable way to verify whether something actually lowered the system latency or if it was just snake oil, a placebo effect, or actually worse without me realizing it.

我经常玩竞技类 FPS 游戏，因此低延迟、稳定的帧时间和高帧率对我来说至关重要。在 Linux 上，有无数的设置可以进行调整（神奇的环境变量、Gamescope、Gamemode、更多的 DXVK 分支等等）。但一直困扰我的是，我没有一种可靠的方法来验证这些调整是否真的降低了系统延迟，还是仅仅是“伪科学”、心理作用，甚至在我不察觉的情况下让性能变得更差。

The device

设备方案

The idea is simple: Strap a device with some kind of light sensor onto a monitor and connect it via USB to the PC to simulate mouse clicks. On click, measure the time between the click and the moment the light sensor detects a change on the screen. This way, you measure the end-to-end system latency.

这个想法很简单：将一个带有光传感器的设备固定在显示器上，并通过 USB 连接到电脑以模拟鼠标点击。点击时，测量从点击动作到光传感器检测到屏幕亮度变化之间的时间。通过这种方式，你可以测量端到端的系统延迟。

To make a long story short, I learned a lot about microcontrollers, soldering, Arduino firmware development, integration time, transimpedance amplifiers, KiCad (just a little) and enclosure design. Here’s what I landed on: An Adafruit QT Py RP2040 acts as a USB HID mouse with 1000 Hz polling rate and fires a click. The moment the click is sent, it starts collecting samples from the photodiode (every ~24 µs). 12,000 samples per click are streamed over serial to the host and logged to a CSV.

长话短说，我学到了很多关于微控制器、焊接、Arduino 固件开发、积分时间、跨阻放大器、KiCad（略知一二）以及外壳设计的知识。最终我的方案是：使用 Adafruit QT Py RP2040 作为 USB HID 鼠标，以 1000 Hz 的轮询率触发点击。点击发送的瞬间，它开始从光电二极管采集样本（每约 24 微秒一次）。每次点击采集的 12,000 个样本会通过串口传输到主机并记录到 CSV 文件中。

Test scenarios

测试场景

I wanted to test three different things:

Display server (X11 vs Native Wayland): A lot of people still use X11 over Wayland because Wayland is said to have much worse input lag.
VRR (on vs off): Variable Refresh Rate / G-Sync / FreeSync / Whatever you want to call it. Also highly debated.
DXVK low-latency fork (on vs off): Referred to as dxvk-low-latency. The maintainer of this fork, netborg, put a lot of effort into developing this frame pacer and it recently got integrated into the official proton-cachyos package.

我想要测试三个不同的方面：

显示服务器（X11 对比原生 Wayland）： 许多人仍然坚持使用 X11 而非 Wayland，因为据说 Wayland 的输入延迟要严重得多。
VRR（开启对比关闭）： 可变刷新率 / G-Sync / FreeSync / 无论你怎么称呼它。这也是一个极具争议的话题。
DXVK 低延迟分支（开启对比关闭）： 简称 dxvk-low-latency。该分支的维护者 netborg 在开发这个帧率调节器上投入了大量精力，它最近已被集成到官方的 proton-cachyos 包中。

Test conditions

测试条件

Hardware: AMD Ryzen 7 5800X3D, NVIDIA GeForce RTX 4070 SUPER, 2x8 GB DDR4 at 3200 MHz, MSI MAG 272QP QD-OLED (2560×1440 / 500 Hz).
Software: CachyOS Kernel 7.1.3, NVIDIA driver 610.43.03, KDE Plasma 6.7.2, Proton-cachyos-native.
硬件： AMD Ryzen 7 5800X3D，NVIDIA GeForce RTX 4070 SUPER，2x8 GB DDR4 3200 MHz，MSI MAG 272QP QD-OLED（2560×1440 / 500 Hz）。
软件： CachyOS 内核 7.1.3，NVIDIA 驱动 610.43.03，KDE Plasma 6.7.2，Proton-cachyos-native。

Note: The default CachyOS kernel scheduler was used. For Flip mode on Wayland, I used the “KWin Debug Console” to ensure the game was running in direct scanout mode (no red border visible).

注：测试使用了 CachyOS 默认的内核调度器。对于 Wayland 上的翻转模式（Flip mode），我使用了“KWin 调试控制台”来确保游戏运行在直接扫描输出模式下（屏幕边缘没有红色边框）。