Linux输入延迟实测：X11、Wayland、VRR与DXVK对比
速览
该技术文章测量了Linux系统上使用X11和Wayland显示服务器时的输入延迟，并考虑了VRR（可变刷新率）和DXVK（DirectX转Vulkan）的影响。通过对比分析不同组合下的延迟数据，为Linux游戏用户和开发者选择图形栈提供参考。结果显示Wayland在某些场景下可能具有延迟优势，但具体取决于配置。
AI 深度解读
背景
两年前，作者将自己的游戏 PC 切换到了 Linux。许多人告诉他 Linux 在帧率（FPS）、帧间隔和输入延迟方面可以比 Windows 表现更好，实际体验后也确实感觉更好。网络上充斥着优化 Linux 游戏性能的建议，例如：
- Wayland 输入延迟高，应使用 X11
- 禁用合成器（使用 "flip mode"）
- 使用延迟优化的 DXVK 分支
- 使用游戏专有内核调度器
- 等等
作者玩的是竞技类 FPS 游戏，因此低延迟、稳定的帧时间和高帧率对他来说至关重要。Linux 上有无数可调整的设置（如各种环境变量、gamescope、gamemode、更多的 DXVK 分支等）。但一直以来让他困扰的是，他无法可靠地验证某项调整是否真正降低了系统延迟，还是只是蛇油（无效果）、安慰剂效应，甚至反而更差而未被察觉。
核心内容
为了量化输入延迟，作者设计了一个简单的测量方案：将一个带有光传感器的设备固定在显示器上，通过 USB 连接到 PC，模拟鼠标点击。点击时，测量从点击到光传感器检测到屏幕变化的瞬间之间的时间差。这样就能测量端到端的系统延迟。
作者参考了已有的开源项目（如 m2p-latency、Open-Source-LDAT 和 OSLTT），最终自行设计并完成了一个测量设备。设备核心是一个 Adafruit QT Py RP2040 微控制器，作为 USB HID 鼠标以 1000 Hz 轮询率发送点击信号。点击发送后，立即以约 24 µs 的采样间隔从光电二极管收集样本。每次点击采集 12000 个样本，通过串口流式传输到主机并记录为 CSV 文件。主机上的工具基于样本建立每次点击的基线，然后找到第一个偏离基线一定量的样本。由于采集 12000 个样本的时间是固定的，因此可以计算出从发送点击到检测到屏幕亮度变化的时间。
作者用这个设备测试了三个变量：
- X11 与 Wayland：许多人认为 Wayland 输入延迟更差，因此仍使用 X11。
- 可变刷新率（VRR / G-Sync / FreeSync）：这也是一个争议点。
- dxvk-low-latency（低延迟 DXVK 分支）：由维护者 netborg 开发，最近被整合到官方 proton-cachyos 包中，通过环境变量
PROTON_DXVK_LOWLATENCY=1启用。这个分支承诺通过帧节流（frame pacer）吸收帧时间波动并防止渲染队列堆积。
测试方法如下：
- 游戏：Diabotical（DirectX 11 游戏），通过 Heroic 启动，使用 Proton。
- 设置：原生屏幕分辨率，100% 渲染比例，垂直同步关闭，其他视频设置尽可能低。
- 通过绑定命令将左键绑定到
/bind mouse_left testlatency，并设置 HUD 显示大的白色方块，以便点击时产生明显的亮度变化。 - 测试条件：所有 Wayland 测试用例通过原生 Wayland 运行（
PROTON_ENABLE_WAYLAND=1），因为已知 XWayland 会引入延迟。但为了对比，添加了两个带 XWayland 的测试用例（仅关闭 VRR）。测试期间仅连接一台显示器。使用默认的 CachyOS 内核调度器。 - 刷新率：系统设置中设为 500 Hz。
- X11 上的 Flip 模式通过
nvidia-settings启用；Wayland 上的 Flip 模式通过 KWin 调试控制台确认已启用（无红色边框表示处于 Flip mode）。 - VRR 在 X11 上通过
nvidia-settings启用（需重启），在 Wayland 上通过 KDE 设置菜单启用（无需重启）。 - 使用优化的
dxvk.conf：- VRR 禁用时：
dxgi.maxFrameRate = 500（FPS 上限为屏幕刷新率）。 - VRR 启用且 dxvk-low-latency 禁用时：
dxgi.maxFrameRate = 497（FPS 上限略低于屏幕刷新率）。 - VRR 启用且 dxvk-low-latency 启用时：使用低延迟 VRR 帧节流设置：
dxgi.maxFrameRate = 480、dxvk.lowLatencyOffset = 70、dxvk.framePace = "low-latency-vrr-500"、dxvk.lowLatencyAllowCpuFramesOverlap = False。
- VRR 禁用时：
- 所有情况均设置
d3d11.cachedDynamicResources = "c"。
测试过程：
- 关闭不必要的软件。
- 启动游戏，开启本地匹配服务器（相同模式和地图）。
- 移动到特定位置，将鼠标放在特定标记点上。
- 运行测试用例迭代：每次 100 次点击，时长约 2 分钟，每个测试用例重复 3 次。
- 游戏内条件：无机器人、无其他玩家、无移动、无回合重启——基本是一个静态场景并无限保持。
- 系统条件：测试期间没有其他重要进程运行。
- 测量设备在所有测试中保持同一位置。
所有 capped（帧率上限）测试用例在测试期间都稳定维持其帧率上限，游戏始终处于 CPU 受限状态。数据干净：没有测试用例产生极端异常值，每个用例都呈现出高斯分布，p5 到 p95 的宽度大约 2 到 3 ms。
主要发现：
- 8 个主要测试用例的中位数（4.21 ms 到 4.93 ms）都落在 0.72 ms 的范围内。
- XWayland 比其对应的原生 Wayland 多出 3.13 ms（中位数 8.06 ms 对比 4.93 ms）。
- 在 uncapped（无帧率上限）情况下，dxvk-low-latency 分支将延迟减少了 0.84 ms。
最快的测试用例情况（X11 + VRR 开启 + dxvk-low-latency 关闭）：中位数约 4.21 ms。
X11 vs Wayland：X11 在每个场景中都胜出，但差距仅为 0.14 到 0.22 ms，分布非常相似。这个差距远不足以解释为什么 Wayland 普遍被认为比 X11 差很多。
VRR：在配对对比中影响最大。开启 VRR 比关闭快 0.26 到 0.45 ms，而且分布更平坦：VRR 开启时 p95-p5 跨度 2.1-2.2 ms，关闭时为 2.6-3.0 ms。这与 VRR 的工作原理一致：帧准备好后立即扫描输出，无需等待下一个扫描输出槽。
dxvk-low-latency：在 capped 测试用例中，差异小而一致，与 X11 vs Wayland 的差异幅度相当。平均而言，Wayland 与 X11 相差 0.18 ms，而使用 dxvk-low-latency 平均加快 0.20 ms。在 uncapped 测试中，dxvk-low-latency 减少了 0.84 ms 的延迟。
关键要点
- X11 与 Wayland 的输入延迟差异极小（约 0.14-0.22 ms），远不足以解释用户对 Wayland 的普遍负面感知。 实际感知差异可能源于其他因素（如 XWayland 的额外延迟、合成器行为差异等）。
- VRR 对延迟有最显著的改善（0.26-0.45 ms），并能使延迟分布更平坦。 推荐在支持 VRR 的显示器上启用。
- dxvk-low-latency 分支在帧率未上限（uncapped）时能减少约 0.84 ms 延迟，在帧率上限时改善较小（约 0.20 ms）。 它通过帧节流来吸收帧时间波动，但在静态 CPU 受限场景中优势有限。
- Flip mode（直接扫描输出）已默认启用，无需额外调整。 在 Wayland 上可通过 KWin 调试控制台确认。
- **XWayland 相对于原生 Wayland 会额外增加约 3.13 ms 延迟，应