geocausa/SP11X1e-audio

# Linux 下的 Surface Pro 11 (X1E) 音频 针对搭载 Qualcomm X1E80100 AudioReach、SoundWire 和双 WSA884x 协议栈的 Microsoft Surface Pro 11，进行基于证据驱动的 Linux 音频引导。 本项目通过捕获的事务交互、其 REV_0D ACDB、预装的 ARM64 Qualcomm 驱动程序以及受控的 Linux 测试，重构了该设备的 Windows 扬声器流水线。Kernel/DT、DSP topology、ALSA UCM 和 PipeWire 策略保持为独立的层级，这样就不会将声学结果误认为是驱动事实。 ## 当前基线 已接受的受控版本为内核 `7.1.5-sp11-audio-clean+`，GRUB ID 为 `sp11-audio-clean`，是在执行 `mrproper` 后，基于源码 commit `f102e3fa8c7e860f3a9ac3ba2043a5fd55242e44` 构建的。 | 领域 | 接受的状态 | |---|---| | 渲染 | 48 kHz，S16_LE，立体声 AudioReach pull endpoint | | 保护反馈 | 双 WSA884x VISENSE 路径，8 kHz/S32_LE/立体声 | | 扬声器保护 | 按捕获的 Windows 顺序进行 SP/SPVI 设置；graph 启动 | | 放大器工作点 | PA 24 (+27 dB)，WSA digital 81 (-3 dB)，双通道 | | PA_AUX | 常规变体选择的 0 dB (`0xdd`)，而非已废弃的 18 dB 实验 | | Dolby | `sp11_dolby_bypass`；无 Dolby 系数或动态处理 | | 操作结果 | 双扬声器，达到可用的上限，在受控的窗口期内无信号丢失 | 该基线包含完整的 Ubuntu 模块目录以及所需的 Phase91 Wi-Fi、触摸、GPI 和 SPI 覆盖配置。确切的已安装哈希值和验收记录位于 [`deploy/audio-clean/README.md`](deploy/audio-clean/README.md) 中。 ``` flowchart LR PW["PipeWire volume"] --> DB["Dolby identity boundary"] DB --> SRC["AudioReach pull endpoint"] SRC --> DSP["Recovered DSP render graph"] DSP --> WSA["WSA macro / SoundWire"] WSA --> L["Left WSA884x"] WSA --> R["Right WSA884x"] L --> VI["8 kHz V/I feedback"] R --> VI VI --> SP["SP + SPVI protection"] ``` 该图展示的是功能流程，并不意味着每一个 Windows 策略分支都已被复现。 ## 已证实的内容 - 与 Windows 兼容的 pull transport、OOB 映射、graph 生命周期回复以及 repeated-prepare 行为在正常的桌面播放下均可正常工作。 - 重构的渲染 graph 包含 29 个恢复的模块、26 条数据边、三个内部控制链路和七个 container。 - 双放大器的 V/I 源均能到达与渲染耦合的反馈后端。 - 捕获的 SP/SPVI 设置和 graph 启动过程可重复完成。 - 上游机器驱动程序的 PA 音量上限曾是 Linux 的主要音量限制。接受的基线仅在受保护的 graph 和 VI 路径存在时，移除了该临时上限。 - 已证实支持运行时 DSP 音量控制和严格允许列表内的 MSIIR 参数传输。该传输是后续 Dolby 工作的先决条件；它本身并不是 Dolby 处理。 - Windows 请求了完整的所选 10,464 字节/107 帧的 graph 校准。Qualcomm GSL 将该校准边界的状态 `3` 视为警告并继续执行。Linux 现在遵循这种严格限制的策略。 校准结论与捕获的事务交互、恢复的 ACDB 以及对哈希匹配的 Windows `qcadcm8380.sys` 的最新反编译结果相绑定；详见 [`2026-08-02-windows-graph-calibration-warning-policy.md`](docs/findings/2026-08-02-windows-graph-calibration-warning-policy.md)。 ## 接受与拒绝的候选方案 | 候选方案 | 决定 | 原因 | |---|---|---| | `audio-clean` | **接受的受控版本** | 双扬声器发声，在使用 Windows 完整选定校准的情况下稳定重启 | | `audio-clean2` | 拒绝 | 移除了一帧 48 字节的校准，与 Windows 行为相悖；仅复现了右声道的物理音频 | | `audio-mapdiag` | 作为基线被拒绝 | 继承自 Clean2 并加入了侵入性的放大器诊断；出现了启动时间过长和单声道故障 | 读取完整的 WSA884x debugfs 寄存器文件并不是被动操作：它会填充 regmap 缓存，随后可能会在 SoundWire 分离后被重放。即使通过管道将该生成的文件传递给过滤器，依然会读取整个映射表。因此，常规的收集器不会执行 WSA884x debugfs 寄存器遍历；完整转储仅作为明确的自主选择项。 ## 待解决的问题 已接受的基线尚不能宣称与 Windows 实现了一对一的完全对等。在结束非 Dolby 阶段之前，剩余的证据收集工作包括： 1. 解决 Windows 独立的放大器重置生命周期与 Linux 稳定的共享重置机制之间的差异。 2. 解码启动后的保护遥测数据（包括 TMax/XMax 读取），并观察保护机制的实际运行情况，而不仅仅是接受配置。 3. 确定 Windows 是否在此特定机器上主动使用 CPS 硬件 sidechain。 4. 确认是否存在真正的逐扬声器校准或硬件不对称性。仅凭设备树中的左/右标签无法证明物理映射关系。 Dolby/Surface APO 行为、系数恢复和过渡处理属于下一个独立阶段。不应在基线中添加任何均衡器或猜测的动态处理来模仿它们。 ## 证据策略 恢复的语料库包含强有力的证据、不完整的片段以及先前 AI 生成的分析。本仓库遵循以下规则： - 将声明与哈希值、地址、捕获记录或可复现的实时观察结果绑定。 - 优先使用预装的 Windows 二进制文件和动态 QGPR/KD 捕获记录，而不是早期会话中生成的文字描述。 - 将假设记录为假设，并保留修正后的结论。 - 除非明确了解分发权限，否则不对原始的厂商固件、ACDB 和转储文件进行版本跟踪。 - 切勿覆盖正在正常工作的内核、DTB、topology 或 UCM 安装；每个候选方案都会获得一个独立的、支持安全回滚的启动项。 - 不要将成功的 PCM open 或 graph 启动视为扬声器保护正在主动限制硬件的证明。 ## 仓库结构 | 路径 | 用途 | |---|---| | [`deploy/audio-clean/`](deploy/audio-clean/) | 接受的启动标识、哈希值和 Phase91 启动资产 | | [`deploy/ucm2/`](deploy/ucm2/) | SP11 ALSA UCM 策略 | | [`deploy/pipewire/98-sp11-dolby-bypass.conf`](deploy/pipewire/98-sp11-dolby-bypass.conf) | 为 Dolby 工作预留的身份边界 | | [`patches/`](patches/) | 有序的 Linux 变更及其状态 | | [`docs/audit/`](docs/audit/) | Windows/Linux 事务交互和来源审计 | | [`docs/findings/`](docs/findings/) | 基于证据的技术发现和修正 | | [`docs/deployment/`](docs/deployment/) | 候选身份、验证关卡和结果 | | [`artifacts/reviewed/`](artifacts/reviewed/) | 经过审查且适合进行版本控制的小型记录 | | [`tools/`](tools/) | 捕获、topology、ACDB 和 QGPR 分析实用工具 | 已确定的决策记录在 [`2026-08-01-audio-clean-baseline.md`](docs/deployment/2026-08-01-audio-clean-baseline.md) 中。 Windows/Linux 启动序列位于 [`2026-07-28-windows-linux-start-transaction-ledger.md`](docs/audit/2026-07-28-windows-linux-start-transaction-ledger.md) 中。 ## 复现跟踪的分析 Lint 并盘点已解码或二进制的 AudioReach topology： ``` ./tools/ar_topology_lint.py topology.bin ./tools/ar_topology_inventory.py topology.bin --json inventory.json --markdown inventory.md ``` 解码 Windows ACDB graph 对象及其选择器/连接元数据： ``` ./tools/ar_graph_open_inventory.py 01e842_POOL.bin --offset 0x35d84 ./tools/acdb_gkv_inventory.py GKVT.bin GKVL.bin --pool 01e842_POOL.bin --json windows-gkv.json ./tools/acdb_sclu_inventory.py 00ea12_SCLU.bin \ --scde 00f4be_SCDE.bin --scdo 00f4f2_SCDO.bin \ --pool 01e842_POOL.bin --json windows-sclu.json ``` 重构类型化的闭包图并解码捕获的激活列表： ``` ./tools/windows_graph_closure.py windows-bundle.json windows-sclu.json \ --json windows-closure.json ./tools/qgpr_activation_inventory.py qgpr.decoded.csv windows-gkv.json \ --json activations.json ``` 本仓库特意不为未知机器提供盲目的单命令安装程序。部署严格绑定到确切的 SP11 硬件、哈希值以及记录在 `deploy/` 和 `docs/deployment/` 中的回滚程序。 ## 范围边界 归档的 PipeWire EQ 已被禁用，不属于对等性研究的一部分。Dolby 身份边界必须保持位透明（bit-transparent），直到充分理解厂商处理机制，从而在不掩盖内核、topology 或保护路径缺陷的情况下对其进行实现和测试。

标签：ALSA, ARM架构, DSP拓扑, Linux音频, PipeWire, 云资产清单, 安全渗透, 网络安全监控, 逆向工具, 逆向工程, 驱动开发