vdi-cloud/docs/kylin-mouse-20261104.md

6.2 KiB
Raw Blame History

麒麟鼠标掉帧继续排查(2026-11-04)

本轮保留的改动是仅麒麟主机协商 limited 视频范围,避免旧版 Sunshine 的额外全范围转换。真实桌面和视频仍为2560×1440、H.264、30Mbps,正常卡片仍请求30FPS。同场景45FPS请求的对照中,实际渲染由21.42提高至28.81FPS(约35%);尚未达到Windows约43~44FPS的既有水平,也未证明物理鼠标到屏幕延迟与Windows相同。

现状与改动

  • Sunshine恢复官方v0.21.0原文件,SHA256为1c3099bf924db3aee759b3d7c05e012569ef8650c400d1479144398795decc71。保持X11、ultrafast、zerolatency、原单线程、暂停UKUI合成器,无额外capability。
  • 盒子vdi-moonlight-rkmpp支持逐主机色彩范围文件:${XDG_CONFIG_HOME:-$HOME/.config}/vdi-terminal/host-color-range/<host>,内容只允许0(limited)或1(full)。仅配置192.168.1.71为0。显式COLOR_RANGE_OVERRIDE环境变量优先,无配置的主机沿用Moonlight默认行为。
  • 服务端实际日志从Color range: [JPEG]变为[MPEG];客户端解码后仍扩展成正常屏幕RGB,不是将黑白截成灰色。未改客户端二进制、分辨率、码率、Windows/Ubuntu卡片或PVE配置。
  • wrapper已部署,语法检查、麒麟/Windows/Ubuntu隔离、显式环境覆盖和非法配置拒绝检查通过,见配置验证。用户明确允许切回麒麟后,已从正常kiosk列表连接,确认父进程为kiosk、2560×1440/30FPS/30Mbps、COLOR_RANGE_OVERRIDE=0,实际2K RKMPP/EGL解码和服务端[MPEG]日志通过。最终保留麒麟桌面连接,见正常入口及最终桌面。

备份:盒子~/vdi-terminal/backups/kylin-mouse-20261104/有原wrapper和desktops.json;麒麟同目录有原sunshine.conf。回退删除麒麟色彩范围文件,下次连接恢复原协商;必要时恢复wrapper备份。没有修改其他主机的配置文件。

测试证据

局部运动GTK源约60FPS,所有以下有效轮次均核对真实未锁屏测试窗口,并发送F8和24次交替点击。每轮请求2560×1440/45FPS/30Mbps,短时顺序测试;网络延迟和抖动有波动,不作为长期保证。

服务端 / 协商 实际渲染FPS 解码ms 队列ms 采用情况
原程序 / full 21.42 7.48 0.15 对照
原程序 / limited 28.81 6.90 0.23 保留limited协商
原程序 / limited / 两线程 25.67 7.09 0.12 已撤销
BGRA兼容副本 / limited 27.17 6.85 0.11 已撤销
BGRA + full-chroma副本 / limited 25.61 10.38 0.13 已撤销
BGRA + bilinear副本 / limited 30.79 7.44 0.13 收益不足以保留二进制维护和色度采样变化,已撤销

数据及日志索引见测试汇总。这轮没有把请求45FPS写成真实达到45FPS。原full与limited静态区域的RGB平均绝对差约0.3~1.3/255,黑白条纹仍包含0和255,小字号与彩色文字已视觉核对;这不是逐像素无损承诺。见色彩核对、limited实际截图。

原始进程线程观察显示Sunshine有一个线程接近占满单核,而盒子呈现队列通常约0.1~0.2ms。通过Linux软件CPU-clock采样,旧版静态FFmpeg的逐像素色彩转换出现在热点中;ELF已剥离符号,地址区间只能粗略分类,不能当作精确函数耗时。记录见采样说明。

未采用的兼容实验

仅对精确SHA256匹配的原文件创建三个独立副本,未覆盖原文件。根据v0.21.0源码与反汇编,两个sws_getContext调用的BGR0立即数由121改为BGRA的28;后续分别测试附加SWS_FULL_CHR_H_INP或改为SWS_BILINEAR。只对独立副本做单文件KYSEC认证。实验服务drop-in已删除,三个副本确认没有进程使用后删除,原版SHA和活动服务已读回确认,见清理记录、恢复状态。未保留任何实验二进制作为正常入口。

依据:Sunshine v0.21.0 video.cpp、FFmpeg n6.0转换初始化、FFmpeg色彩范围转换。

回显延迟边界及后续

增加了F9翻转画面黑白标记的探针:盒子在发出合成按键前计时,轮询实际解码视频所在X11根窗口,看到标记翻转后结束。该方法包含工具启动、串流往返和轮询,排除物理USB输入和显示面板扫描。

用户授权切回麒麟后,使用同一个未锁屏的动态源、原版服务端、相同2560×1440/30FPS/30Mbps完成顺序对照,每组24次,均无超时:

配置 实际渲染FPS 解码ms 合成输入回显P50 ms P95 ms
full原协商 23.35 9.54 150.99 186.38
limited保留配置 27.25 6.96 143.57 173.03

见完整对照数据。视频更新约提高17%;回显分布重叠、网络延迟也不同,24个样本不足以证明显著或大幅的延迟下降,更不能宣称达到Windows几乎无延迟。该探针也不能替代物理输入到屏幕的测量。

此前full/30FPS的一组24次P50约163ms、P95约190ms,后续超出临时串流期限,盒子随后已连接Windows,完整收尾未完成;保留原始JSON和部分日志用于审计,不混入上述完整对照。临时GTK和临时串流服务已停止,最终使用正常kiosk串流。

麒麟2vCPU的软件捕获/颜色转换/编码链路仍然限制视频更新。若目标是Windows同等的视频响应,需要进一步实现并验证转换并行化/硬件编码;若目标是指针本身不等待视频,则需要实现自动形状同步、显隐、热点和可靠交接的独立光标通道。现有受控原型尚不满足这一要求,不能用普通本地箭头叠加冒充完成。