# Ubuntu 点击与悬停延迟新方案（2026-11-06）

## 结论

当前延迟的关键不是鼠标速度，也不是盒子渲染。VM102 仍由 Sunshine 的 `libx264` 软件编码输出，盒子端解码、队列和渲染约为 12ms、0.2ms 和 2ms；已测得 Ubuntu KMS 45FPS 的 hover 回显 P50/P95 约 196/220ms，按钮点击约 304/378ms。要接近 Windows，必须优先改变 Ubuntu 端的“真实硬件编码或捕获到编码的零拷贝路径”。

Sunshine 官方文档明确指出：Linux 的 X11 捕获 CPU 开销最高，应尽量使用 KMS；硬件编码可使用 VA-API、QuickSync 或 NVENC，KMS 与 VA-API 兼容。当前已保留 KMS + 原生光标组合，但编码仍是软件路径。[Sunshine 配置文档](https://docs.lizardbyte.dev/projects/sunshine/latest/md_docs_2configuration.html)

## 新计划

### 1. 先做只读硬件可行性检查

检查 PVE 宿主的 Intel `00:02.0` 是否支持稳定的 VFIO 直通、是否有可用的 i915/mdev 能力，以及宿主是否依赖这块核显提供 PVE 或其他虚拟机图形服务。检查 Ubuntu 内核、`/dev/dri` 权限、`vainfo` 和 H.264 编码入口。检查只读完成前不改 VM、不重启宿主。

当前 PCI 盘点显示：Intel 4 代核显在 `00:02.0`，NVIDIA GTX 965M 在 `01:00.0` 且已分配给 Windows VM100，因此不能挪用 NVIDIA；Ubuntu 的 `virtio-gl` 只提供 VirGL 图形翻译，不等于真实硬件编码。[QEMU VirtIO GPU 文档](https://www.qemu.org/docs/master/system/devices/virtio/virtio-gpu.html)

已完成的只读预检显示 Ubuntu 当前只暴露 `virtio_gpu_dri.so`，没有 `i965`/`iHD` 编码驱动；`i965-va-driver`、`vainfo` 等包在 Ubuntu 软件源中可用，但安装软件包本身不能让 VirGL 变成真实 Intel 编码设备。预检快照见 [pve-readonly-preflight.json](evidence/ubuntu-latency-plan-20261106/pve-readonly-preflight.json)。

### 2. 首选路径：给 Ubuntu 使用真实 Intel 编码设备

如果只读检查确认宿主可以安全释放 Intel 核显，则建立 VM102 的备份，安排宿主维护窗口，把 Intel 核显以 VFIO 直通方式交给 Ubuntu，客体安装 Haswell 对应的 VA-API 驱动，先用独立 `vainfo` 和 FFmpeg 编码测试，再让 Sunshine 只使用 `encoder=vaapi`、`capture=kms`。Haswell 属于 `intel-vaapi-driver` 支持的 H.264 编码平台，但必须看到真实 i915 设备和 `VAEntrypointEncSlice`；VirGL 暴露的伪 VAAPI 已经在现场触发过 Mesa/virgl 崩溃，不能继续沿用。[Intel VA-API 驱动支持表](https://github.com/intel/intel-vaapi-driver/blob/master/README)

验收条件是 Sunshine 日志稳定出现 `Creating encoder [h264_vaapi]`，持续 10 分钟无崩溃、无回退到 `libx264`，并且 2560×1440 的 hover/click/drag 测试延迟显著下降。失败时只恢复 VM 配置和 Ubuntu 驱动，不碰 Windows VM100、麒麟 VM101 或盒子客户端。

如果宿主不能释放核显，第二选择是增加一块可被 Ubuntu 独占的低功耗硬件编码 GPU。仅升级 VirGL、增加虚拟显存或安装 Mesa 软件包不能替代这一步。

### 3. 无法获得真实 GPU 时的保底方案

保留当前 `capture=kms`、`host` CPU、`virtio-gl`、H.264 和原生光标，只做有基准的两项实验：

1. 评估 QEMU `virtio-gpu` 的 host memory/blob 配置，目标是减少桌面渲染读回；这只可能改善捕获前的渲染，不能把软件编码变成硬件编码。
2. 在宿主只有 4 个物理核的前提下，禁止盲目增加 VM vCPU 或继续堆 x264 线程；每次实验必须用同一套 2K 动态窗口和真实 GNOME 点击/拖拽数据验证，P95 变差就回退。

如果没有真实硬件编码，2K 下无法承诺达到 Windows 的约 90ms。此时应提供两个明确 profile：2K 画质优先，以及 1080p/更高帧率低延迟；由使用场景选择，而不是继续隐藏软件编码瓶颈。

## 验收与回退

- 同一盒子、同一网络、同一 60Hz 输入注入，分别记录 hover、button click、masked input、长按框选的 P50/P95。
- 同时记录 Sunshine 实际编码器、收流 FPS、主机处理延迟、网络 RTT、盒子解码/渲染耗时。
- 只有出现真实 `h264_vaapi`/`h264_qsv` 且延迟和尾部都改善，才保留新路径；出现崩溃、软件回退、画面损坏或 P95 变差立即恢复备份。
- 全部测试结束后恢复 Ubuntu 正常 Sunshine 服务、关闭原生光标守护租约，盒子回到桌面列表。

该方案的核心变化是先验证“真实硬件编码是否可用”，而不是再调鼠标主题、速度、虚拟显存或客户端队列。


## 2026-11-06 直通验证结果

本轮按计划对 VM102 做了可回退试验：临时使用 `hostpci0=0000:00:02.0,pcie=1,rombar=0` 和 `vga=std`，Ubuntu 成功识别 Intel HD 4600 的 `i915`，`vainfo` 显示 `VAProfileH264High` 与 `VAEntrypointEncSlice`。Sunshine 也能在启动探测中识别 `h264_vaapi`。

但这台 VM 的桌面显示仍由虚拟 Bochs/Virtual-1 提供。启用 KMS 后 Sunshine 在查找 DRM monitor 时长时间阻塞，Moonlight 的 `launch` 请求超时；重启 Sunshine 时 Xorg/xrandr 又出现长时间卡住，Sunshine 需要强制终止。切换 X11 捕获尚未能形成稳定串流，试验因此判定失败。

已完成回退并重启宿主恢复 i915：VM102 当前为 `vga=virtio-gl`、无 `hostpci0`，Ubuntu Sunshine 恢复 `capture=x11`、`encoder=software`；VM100、VM101、VM102 均为运行状态，Windows 的 NVIDIA 直通和麒麟配置未修改。完整过程证据见 [intel-vaapi-trial-final.json](evidence/ubuntu-latency-plan-20261106/intel-vaapi-trial-final.json)。

结论：当前这台宿主上，单纯把 Intel 核显直通给 Ubuntu 不能稳定打通“虚拟显示捕获 -> VAAPI 编码”链路，不能保留为生产优化。要继续把 Ubuntu 的交互回显压到 Windows 水平，需要给 Ubuntu 独占一块能同时提供显示/编码的 GPU，或改用支持零拷贝显示输出的虚拟 GPU 方案；继续调鼠标速度、虚拟显存和客户端队列不会消除这条编码瓶颈。