2.4 KiB
Ubuntu 交互响应深度调优（2026-11-05）
本轮只改 Ubuntu VM102。保留 2560×1440、原生 Ubuntu 光标、30Mbps H.264 和 RKMPP/EGL 客户端；Windows、麒麟和 NVIDIA 直通没有改动。
现场启用了 KMS 捕获与原生独立光标的组合：Sunshine 使用 /dev/dri/card1 的 virtio_gpu atomic primary scanout，客户端继续通过已验证的原生光标通道同步形状、热点和位置。KMS 守护校验唯一 primary plane、CRTC_W/CRTC_H=2560×1440、驱动名 virtio_gpu，不请求 cursor hotspot plane，因此不会把第二个光标编码进视频。virtio atomic 客户端的 legacy crtc_id/fb_id 保持为 0，守护不再把这两个无效字段当作活动状态；真实捕获由 Sunshine 自己完成。
对比结果（60Hz XTest 注入，读解码视频中的唯一编号；不含物理 USB、网络之外的面板扫描，也不等于本地箭头延迟）：
| 场景 | KMS 45FPS | X11 45FPS |
|---|---|---|
| 长按框选回显 P50 / P95 | 195.9 / 246.6ms | 250.1 / 311.5ms |
| 视频中可见新编号更新 | 16.0/s | 10.6/s |
| 实际按钮点击回显 P50 / P95 | 约 304 / 378ms | — |
| masked 输入字符回显 P50 / P95 | 约 165 / 182ms | — |
28 次点击的编号、位置和释放均通过；7 种原生光标形状/显隐的几何和像素最大差为 0，视频背景没有混入指针。KMS 与原生光标的正常退出、空闲后重连、守护进程被强制结束后的 X11 恢复、再次重连均通过。证据在 docs/evidence/ubuntu-deep-latency-20261105/，包括 drag-kms-native45.json、drag-x11-native45.json、response-kms-async.json、cursor-kms-native45.json 和 kms-lifecycle.json。
45FPS 请求只带来有限收益；软件编码 min_threads=4 的回显中位数约 197ms、尾部变差，已撤回。失败的 VirGL 硬编码和异步通知实验也没有留在运行环境。最终当前会话保持 KMS + 原生光标；Sunshine 配置仍是软件编码，未宣称已达到 Windows 的约 90ms 或“零延迟”。真实业务应用的后端认证没有写入测试数据；本轮只对实际 GTK 按钮、masked entry 和合成提交做了定量，未把合成提交冒充真实登录成功。
当前剩余瓶颈是 VM102 的 X11/virtio 读回和宿主 CPU 软件编码。要进一步接近 Windows，需要可用的 Linux 硬件编码/低开销捕获路径或更高性能 GPU；不能靠继续加快本地箭头、盲目提高 FPS 或修改鼠标主题解决。