两年前，独立开发者Marco Nett把游戏主机从Windows换成Linux，社区里流传的一堆延迟优化偏方也跟着装了个遍：弃用Wayland改用X11、关掉合成、换上魔改版DXVK……但没人告诉他这些改动到底有没有用。2026年7月13日，他公布了自己两年攒出来的答案：一台用RP2040微控制器加光电二极管做的click-to-photon延迟测量仪，每次点击采样一万两千次，直接把"感觉快"变成了毫秒数字。
结果和社区共识拧了个方向。X11和原生Wayland的延迟差只有0.14到0.22毫秒，几乎感觉不出来；真正拖后腿的是运行在Wayland上的XWayland兼容层，单独就能多出3.13毫秒延迟，比其他所有变量加起来还多。这台设备第一次把Linux游戏圈吵了多年的"玄学清单"，按到了仪器上称重。
一台自制传感器，量出了什么
测试机是Ryzen 7 5800X3D + RTX 4070 SUPER，接一块500Hz QD-OLED显示器，系统跑CachyOS + KDE Plasma 6.7.2，通过proton-cachyos-native（内置DXVK 3.0）运行FPS游戏Diabotical。他搭了一个2×2×2的测试矩阵：X11还是Wayland、VRR开还是关、用不用已经并入proton-cachyos的dxvk-low-latency帧率控制器。每种组合测三轮，每轮一百次点击，一共三百次采样，场景是无人无干扰的静态空场景，保证结果只反映系统本身，不掺杂游戏内部的帧时间波动。
八种主配置的中位数全部挤在4.21到4.93毫秒之间，最快和最慢只差0.72毫秒。换句话说，只要不碰XWayland，X11党吵了这么多年的优势，量出来还不到零点二毫秒。
VRR才是真正的加速器，XWayland才是真正的坑
四个变量摆在一起对比，VRR（可变刷新率）带来的改善最明显，达到0.26到0.45毫秒，还能把延迟分布的宽度从2.6-3.0毫秒收窄到2.1-2.2毫秒——不仅更快，波动也更稳。dxvk-low-latency在帧率封顶的场景下只快0.10到0.29毫秒，但一旦不限帧、GPU接近满载，作用立刻放大：延迟从5.27毫秒降到4.43毫秒，代价是帧率从715掉到670，GPU占用率从100%降到95%-97%——它靠故意不把GPU喂饱来换延迟。
真正的异常值在XWayland。默认DXVK下，通过XWayland运行游戏比原生Wayland多出3.13毫秒延迟，是VRR效果的近十倍。有意思的是，换上dxvk-low-latency能在这条路径上挽回2.11毫秒——说明这更像是渲染队列堆积的问题，不是XWayland协议本身天生就慢。Marco Nett此前维护这个fork时，还用NVIDIA Reflex Analyzer在高帧率合成测试里测过类似排序：X11直出模式1.0-4.1毫秒最快，原生Wine-Wayland加VRR紧随其后（1.7-4.6毫秒），而XWayland加V-Sync能拖到11.9-14.7毫秒——两次测试，同一个反派。
真正该吵的不是X11还是Wayland，是要不要碰XWayland。
500Hz静态场景之外，结论能走多远
这些数字都是在"最佳案例"条件下测出来的：500Hz显示器、CPU-bound的静态空场景，加上手动调优过的dxvk.conf——dxgi.maxFrameRate、lowLatencyOffset、framePace这些参数是精心配的，不是打开一个开关就能复制的默认体验。Hacker News上有评论提醒，把KWin一家合成器的表现直接贴上"Wayland"标签太宽泛，Mutter、Gamescope、Sway、Hyprland的调度策略完全可能不一样；Reddit上也有人质疑，3.13毫秒的XWayland惩罚会不会只是NVIDIA驱动加KWin这套组合特有的现象，其他平台上类似测试给出的差距要小得多。
- 风险.结论建立在500Hz、静态空场景和调优过的DXVK参数之上，60/120Hz显示器与真实混战场景下的效果，目前还没人验证。
对普通Linux玩家来说，眼下能落地的排序很清楚：先开VRR，能避开XWayland就避开，GPU压力大的游戏再考虑上低延迟fork，X11还是Wayland反而是这张清单里最不用纠结的一项。