Linux输入延迟实测：X11 vs Wayland、VRR与DXVK低延迟的影响
两年前，我把游戏PC的系统换成了Linux。一直有人说，在帧率（FPS）、帧生成稳定性和输入延迟方面，Linux的表现远胜Windows，实际体验后，我确实感觉流畅不少。
网上到处都是Linux游戏优化教程：
我主打竞技类FPS游戏，低延迟、稳定帧生成、高帧率对我至关重要。在Linux上，相关的可调设置多不胜数——比如各种"魔法环境变量"、gamescope、gamemode，还有更多DXVK分支版本等等。
但始终困扰我的是，我没有可靠的方法验证：某个设置真的降低了系统延迟，还是只是噱头、安慰剂效应，甚至在我没察觉的情况下反而拖慢了速度。
我的思路很简单：给显示器装一个带光线传感器的设备，通过USB连接电脑来模拟鼠标点击。点击时，测量从发出点击指令到光线传感器检测到屏幕画面变化的时间差。
这样就能测出端到端的系统延迟。
现在已经有几款这类开源设备了，比如m2p-latency和Open-Source-LDAT，但我刚开始这个副业项目时，只有OSLTT可选。我完全不懂硬件，只能研究它的电路图，以此为基础粗略设计自己的设备。
直到本月项目收尾时，我还融入了另外两款设备的不少设计思路。
简而言之，我在这个过程中学到了大量知识：微控制器操作、焊接技术、Arduino固件开发、传感器积分时间、跨阻放大器原理，还粗浅了解了KiCad和外壳设计。
最终成品的测试目标有三个：
很多人至今还在用X11而非Wayland，因为大家都说Wayland的输入延迟高得多。只要搜一搜，就能看到大量用户抱怨Wayland"手感不对劲"。
可变刷新率（VRR），也就是大家常说的G-Sync、FreeSync之类的技术，相关争议也很大。
下文统一称其为dxvk-low-latency或低延迟模式。
PROTON_DXVK_LOWLATENCY=1。这个DXVK分支的宣传卖点，是让我决定再次尝试桌面Linux的关键原因之一。像dxvk-low-latency这样的帧生成控制器，最大优势在于能抵消帧生成波动，避免渲染队列堆积。
我采用的测试方法是固定游戏场景（详情见下文），所有测试都处于纯CPU受限状态，因此观测不到帧生成波动。但这和真实游戏场景相差甚远——实际游戏中，无论是内的画面变化，还是后台进程占用资源，都可能导致帧生成不稳定。
为了展示帧生成控制器的作用，我额外设置了两组帧率不封顶的测试用例。
所有Wayland测试用例都通过原生Wayland模式运行（设置PROTON_ENABLE_WAYLAND=1），因为我知道XWayland会增加延迟。不过为了对比，我还是加了两组XWayland测试用例（仅关闭VRR的情况）。
| 硬件配置 |
|---|
| AMD Ryzen 7 5800X3D |
| NVIDIA GeForce RTX 4070 SUPER |
| 2×8 GB DDR4 3200 MHz |
| MSI MAG 272QP QD-OLED X50（2560×1440 / 500 Hz） |
| MSI B450 GAMING PRO CARBON AC |
测试期间仅连接一台显示器。
| 软件配置 | 版本 |
|---|---|
| CachyOS | - |
| 内核 | 7.1.3-2-cachyos |
| NVIDIA驱动 | 610.43.03-1 |
| KDE Plasma | 6.7.2-1.1 |
| xorg-server | 21.1.24-1.1 |
| proton-cachyos-native | 1:11.0.20260602-3 |
| dxvk（通过proton-cachyos） | 3.0 |
使用CachyOS默认内核调度器。
nvidia-settings（修改该设置需重启电脑）
Wayland下的翻转模式（或称"直接扫描输出"）与位块传输模式（合成模式）： 没有手动设置选项，由 compositor 自行决定对帧进行合成还是直接扫描输出。
确认游戏处于翻转模式的方法：打开"KWin调试控制台"（一款图形界面工具），在"特效"标签页启用showcompositing。确保游戏全屏运行且处于焦点状态，若游戏画面边缘没有红色边框，说明当前是翻转模式。
为保证对比公平，不同场景使用了针对性优化的dxvk.conf：
- 设置
dxgi.maxFrameRate = 500（帧率封顶为屏幕刷新率） - 设置
dxgi.maxFrameRate = 497（帧率略低于屏幕刷新率）
dxgi.maxFrameRate = 480
dxvk.lowLatencyOffset = 70
dxvk.framePace = "low-latency-vrr-500"
dxvk.lowLatencyAllowCpuFramesOverlap = False
所有场景均设置d3d11.cachedDynamicResources = "c"。
测试选用的游戏是Diabotical，一款DirectX 11游戏，通过Heroic启动器搭配Proton运行。
游戏有一条隐藏指令，可以短暂隐藏界面。我将该指令绑定到鼠标左键（/bind mouse_left testlatency），同时设置一个显示白色大框的HUD，这样点击时屏幕亮度会产生明显变化。
所有帧率封顶的测试用例，在测试期间都稳定维持着帧率上限，且全程处于CPU受限状态。
测试数据很规整：所有用例都没有出现异常值，延迟分布均呈钟形，p5到p95的区间宽度约为2至3毫秒。
有三个结论十分突出：
先看延迟最低的情况：
那么，X11的延迟真的比Wayland更低吗？
确实更低，但差距极小，完全无法解释为什么大家普遍觉得Wayland比X11差很多。
| 配置 | X11 | Wayland | 差值 |
|---|---|---|---|
| 低延迟模式+VRR | 4.21 ms | 4.38 ms | +0.17 ms |
| 仅低延迟模式 | 4.64 ms | 4.83 ms | +0.19 ms |
| 仅VRR | 4.45 ms | 4.67 ms | +0.22 ms |
| 默认设置 | 4.79 ms | 4.93 ms | +0.14 ms |
X11在所有场景中都领先，但差距仅为0.14至0.22毫秒。
两者的延迟分布也非常相似：
VRR在所有对比组中影响最大：开启后比关闭时快0.26至0.45毫秒。
| 配置 | VRR关闭 | VRR开启 | 差值 |
|---|---|---|---|
| X11+低延迟模式 | 4.64 ms | 4.21 ms | -0.43 ms |
| 仅X11 | 4.79 ms | 4.45 ms | -0.34 ms |
| Wayland+低延迟模式 | 4.83 ms | 4.38 ms | -0.45 ms |
| 仅Wayland | 4.93 ms | 4.67 ms | -0.26 ms |
VRR还能让延迟分布更平缓：开启VRR时，p95与p5的差值为2.1至2.2毫秒，而关闭时为2.6至3.0毫秒。
这与VRR的工作原理一致：帧渲染完成后立即扫描输出，无需等待下一个扫描时隙。
在帧率封顶的场景中，dxvk-low-latency带来的提升虽小但稳定，幅度和X11与Wayland的差距相当。Wayland与X11的平均差值为0.18毫秒，而开启dxvk-low-latency后平均能快0.20毫秒。
| 配置 | 低延迟模式关闭 | 低延迟模式开启 | 差值 |
|---|---|---|---|
| X11+VRR | 4.45 ms | 4.21 ms | -0.24 ms |
| 仅X11 | 4.79 ms | 4.64 ms | -0.15 ms |
| Wayland+VRR | 4.67 ms | 4.38 ms | -0.29 ms |
| 仅Wayland | 4.93 ms | 4.83 ms | -0.10 ms |
在帧率不封顶的场景中，dxvk-low-latency的真正优势才得以体现：它能平滑不稳定的帧生成节奏，避免渲染队列堆积。
这款帧生成控制器的实现逻辑是确保GPU不会被完全占满，让游戏始终接近但不会完全进入GPU受限状态。测试中可以看到，开启dxvk-low-latency时GPU利用率为95-97%，关闭时则达到100%。代价是帧率略有下降。
| 指标 | 低延迟模式关闭 | 低延迟模式开启 | 差值 |
|---|---|---|---|
| 延迟 | 5.27 ms | 4.43 ms | -0.84 ms |
| FPS | 715 | 670 | -45 |
此前所有Wayland测试都通过原生Wayland模式运行（设置PROTON_ENABLE_WAYLAND=1，或在Heroic启动器中开启"启用Wine-Wayland（实验性）"选项）。关闭该选项后，游戏会通过XWayland运行，这时延迟问题就会变得很严重。
| 配置 | 原生Wayland | XWayland | 差值 |
|---|---|---|---|
| 低延迟模式 | 4.83 ms | 5.95 ms | +1.12 ms |
| 默认设置 | 4.93 ms | 8.06 ms | +3.13 ms |
未开启dxvk-low-latency时，XWayland会增加3.13毫秒的延迟，比我测得的其他所有优化效果的总和还要大。这并非是个别异常帧拉高了平均值，而是整体延迟分布都出现了偏移：
值得注意的是，在XWayland测试中开启dxvk-low-latency后，延迟降低了2.11毫秒，是所有测试场景中提升最大的一次。
以上结果是在最佳条件下测得的（帧率稳定在封顶值、CPU受限），且仅针对我的硬件和软件环境。
其他设备上的绝对延迟数值可能不同，但各测试用例带来的延迟变化幅度应该大致相近。在刷新率更低的显示器上，VRR和低延迟模式带来的提升可能会更明显。
XWayland增加了3.13毫秒延迟，超过其他所有效果的总和。
X11确实比Wayland快，但差距仅为0.14至0.22毫秒。目前已有优化KWin的相关工作，这个差距很可能会很快缩小。说不定其他Wayland compositor已经做得更好了。
VRR在所有对比组中都更快速（提升0.26至0.45毫秒），还能让延迟分布更平缓。
在帧率封顶场景中，dxvk-low-latency能带来0.10至0.29毫秒的不错提升，但它的真正实力体现在帧率不封顶的场景中——相比默认DXVK，延迟降低了0.84毫秒。
此外，在不得不使用XWayland的场景中，它能挽回整整2.1毫秒的延迟损失。
排除XWayland的影响，将所有优化拉满（X11+VRR+低延迟模式），对比默认设置（我认为现代Linux系统的默认设置是原生Wayland），中位数延迟降低了0.72毫秒。
这个数字听起来不大，但原始延迟并不能反映全部情况：VRR还能减少延迟抖动，而dxvk-low-latency的帧生成控制器在处理真实游戏中的帧生成波动和GPU受限场景时表现出色。
David Ramiro制作了m2p-latency设备，并在文章《打造输入延迟测试仪（因为"Wayland手感不对"不是量化指标）》Building an Input Latency Meter (Because ‘Wayland Feels Off’ Isn’t a Metric)中对比了X11和Wayland，得出了类似结论：
原生Wayland和原生X11表现相当（延迟均约为7毫秒），而在他的测试中XWayland的延迟几乎翻倍。
farnoy使用Open-Source-LDAT进行了大量测试，并在文章《Linux延迟测量与 compositor 调优》Linux latency measurements and compositor tuning中指出，应尽量避免使用XWayland。
Themaister在文章《我用VK_EXT_present_timing测量输入延迟的副业》My side quest measuring input latency with VK_EXT_present_timing中介绍了一种无需外部硬件的测试方法：通过/dev/uinput注入输入信号，再在GPU端检测画面变化。
这种方法无法测量端到端系统延迟，但排除了USB和显示器本身的延迟，仅测量PC内部的延迟。该项目可在GitHub上找到。