Linux HDMI 无声：路线图与未来步骤

本文是 Google Kaisa（Chromebox 10 代）+ Coreboot 下 Linux HDMI 无声音问题的 主路线图。技术细节与论证见各专项文档；本文只固定 顺序、产出物与维护方式。

全文档索引：INDEX.md
项目总览与问题表：../../README.md
换机事实与当前状态：WORK_PROGRESS.md（与本文分工见下表）

文档角色（与 `WORK_PROGRESS` 的分工）

文档	职责
本文（路线图）	阶段顺序与建议：各阶段「该做什么」、已排除方向、成功标准、维护方式（Mermaid 与章节编号）
`WORK_PROGRESS.md`	真机事实：换机/clone、日期、当前 `uname -r` / 补丁应用、阻塞项

读顺序以本文为准；查 「现在卡在哪、上次验证是哪天内核」 以 WORK_PROGRESS 为准。两文件互相链接；若冲突，对照后更新事实（WORK_PROGRESS）或 阶段定义（本文）。

一、问题与范围

硬件：Google Kaisa；Coreboot；HDMI 走 SOF + iDisp / DisplayPort 音频 链路。
典型现象：Linux 下 HDMI 无输出或无法稳定打开 PCM；3.5mm 通常正常。同机 ChromeOS / Windows HDMI 正常 时，问题集中在 Linux 内核 / SOF / 用户态路由，而非线缆或显示器本身。
dmesg 常见线索：STREAM_PCM_PARAMS IPC 失败、约 -5（EIO），常与 pcm2/3/4（HDMI1/2/3） 某条相关（物理口与编号需实测对照）。
非本仓库机型：其它机器 HDMI 无声原因可能完全不同（独显、默认 sink、PipeWire 等），勿直接套用本仓库内核补丁；可借用阶段 1 的排查套路，根因结论见各文档。

源码对比后的修复分支（A–D 决策）：FIX_PLAN_HDMI_FROM_SOURCE_ANALYSIS.md（与本文互补，勿两处重复维护同一张现象表）。

二、已排除或低期望方向

下列方向在仓库内已有结论或真机反馈；重复投入前请先读链接，避免走弯路。

方向	结论摘要	详见
仅替换拓扑（tplg）	与 ChromeOS 等效，单独换 tplg 不能恢复 HDMI	ANALYSIS_Audio.md
仅换 intel-signed / community SOF 固件	不能单独恢复 HDMI；可能影响插拔检测	OPERATION_Force_Intel_Signed_Firmware.md、WORK_PROGRESS.md
旧 0002（iDisp `TRIGGER_POST`）	真机无效；已从仓库删除	REANALYSIS_Linux_HDMI_Audio_Kaisa.md、DIFF_SUMMARY.txt
Ubuntu Mainline 5.15 deb（如 kernel.ubuntu.com）	真机 HDMI 仍无声且 3.5mm / WiFi 异常；不等于 ChromeOS 5.15	REANALYSIS_Linux_HDMI_Audio_Kaisa.md
NHLT 缺失	不是根因（ChromeOS 也无 NHLT 仍正常）	ANALYSIS_Audio.md 第六节

三、分阶段路线图

flowchart LR
  phase1[phase1_baseline_user]
  phase2[phase2_kernel_0001]
  phase3[phase3_deep_diff_bisect]
  phase4[phase4_upstream_issue]
  phase1 --> phase2 --> phase3 --> phase4

阶段 1：用户态基线

目的：确认设备枚举、默认输出、以及 dmesg 是否已出现 IPC 错误（避免「选错 sink」假阳性）。

aplay -L / aplay -l，对 每个 HDMI 类 plughw:卡号,设备号 执行 speaker-test（见 REPAIR_Plan_Audio.md 1.2 节）。
运行 collect_linux_audio_topology.sh（建议 sudo），输出到 audio_topology/collected/；其中含 SOF / HDMI / IPC 基线 dmesg 过滤。
图形环境下确认默认播放设备未锁死在打不开的 HDMI 上。

产出：带时间戳的采集文件，便于前后对比。

阶段 2：HWE 6.17 与 0001 补丁

目的：在发行版栈上验证仓库内 0001（ipc3-pcm.c：FREE / trigger 使用 sof_ipc_tx_message + 回复），并正确安装自编内核与模块包。

源码与版本：见 kernel-src/README.md；在 Ubuntu Noble 上与运行内核一致的 apt source linux-hwe-6.17=...。
补丁校验： scripts/verify-ubuntu-hwe617-0001-patch.sh（patch --dry-run；若树中已含补丁内容会提示跳过）。
构建与安装：PATCH=... scripts/ubuntu-hwe-617-build.sh apply → deps → build；安装见 OPERATION_Install_CustomKernel_Ubuntu_HWE617.md（linux-image-unsigned、linux-modules + modules-extra、必要时 iwlwifi 等）。
0001 与 STREAM_PCM_PARAMS：0001 对齐 ChromeOS 的 FREE/trigger 路径；不改变 hw_params / STREAM_PCM_PARAMS 发送逻辑。若 HDMI 仍失败且 dmesg 仍报 PARAMS，见 STREAM_PCM_PARAMS_CHROME_UBUNTU_NOTES.md、DIFF_SUMMARY.txt。

产出：可启动的自编内核；复测后新的 collected/ 与 dmesg 片段。

阶段 3：深度对照与可选 trace

目的：在 6.x 上定位 iDisp / SOF IPC 与 ChromeOS 5.15 的差异，为新补丁或 bisect 提供依据。

克隆 ChromiumOS 5.15 内核树： WORK_PROGRESS.md 第二节。
流程与导出：git unshallow、按文件 diff： OPERATION_ChromeOS_Kernel_Deep_Diff.md；脚本 diff-chromeos-ubuntu-sound.sh、export-chromeos-ubuntu-sound-file-diffs.sh。
仍无声时一键列文档与条件运行对照： linux-hdmi-followup-workflow.sh。
可选：按 OPERATION_Kaisa_SOF_HDMI_Trace.md、README_TRACE_KAISA.md 抓取带 IPC 载荷的日志。

产出：reference/ 下 unified diff（若已配置双树）、或明确的「缺哪棵树」记录。

阶段 4：上游协同

目的：将 最小复现包 交给 SOF / ALSA 社区，避免闭门造车。

清单与邮件模板： UPSTREAM_SOF_Kaisa_HDMI_REPRO.md。

四、成功标准（建议）

客观：对目标 HDMI 口播放时，dmesg 中无与本次播放相关的 STREAM_PCM_PARAMS / ipc tx error（或已确认为无害/已修复）。
主观：显示器扬声器或耳机有稳定输出。
回归：3.5mm、WiFi 等与本次改动无关的子系统无意外损坏（自编内核时注意装全模块包）。

五、维护与「当前阶段」

路线图正文为本文件；换机与源码 URL、实验结论以 WORK_PROGRESS.md 为准，两者应同步（WORK_PROGRESS 内「Linux HDMI 当前阶段」见该文件顶部）。阶段或成功标准相关结论变更时，须按 DOCUMENTATION_ARCHITECTURE · FR17 交叉核对两处，避免事实矛盾。
任务编号 L1–L4 与阶段对应关系见根 README.md 任务列表。

六、相关文档速链

用途	链接
源码对比驱动的修复计划（阶段 A–D、决策分支）	FIX_PLAN_HDMI_FROM_SOURCE_ANALYSIS.md
双树源码对比摘要	SOURCE_DIFF_CHROMEOS515_UBUNTU617.md
Linux 分步操作与索引	REPAIR_Plan_Audio.md
长文分析（Mainline 误区、自定义内核注意）	REANALYSIS_Linux_HDMI_Audio_Kaisa.md
API 对照（`playback_only` 等）	CHROMEOS_VS_UBUNTU_HDMI_NOTES.md

8.4 KiB Raw Blame History Unescape Escape