14 · 硬件探测与调优¶

硬件支持不是一个中央“机型数据库”。Quattro 用可组合探测命令和顺序执行的幂等脚本，把厂商、设备类别与具体 workaround 拆开。

两层结构¶

flowchart LR
    Apply[omarchy-apply-hardware] --> List[install/hardware/all.sh]
    List --> Gate1{NVIDIA?}
    List --> Gate2{Intel model?}
    List --> Gate3{Framework/Surface/ASUS?}
    List --> Gate4{设备/能力存在?}
    Gate1 --> Action1[驱动/KMS]
    Gate2 --> Action2[VAAPI/firmware/kernel]
    Gate3 --> Action3[机型 workaround]
    Gate4 --> Action4[input/network/audio]

omarchy-apply-hardware 负责 root/user/deferred 上下文与总编排；install/hardware/all.sh 只定义稳定顺序；每个脚本自己 gate 并在不适用时成功跳过。

detector 用退出码组合¶

omarchy-hw-* 命令尽量把“是否满足条件”编码为 shell exit status，因此安装脚本可以自然写：

if omarchy-hw-nvidia; then
  # apply NVIDIA-specific state
fi

探测来源包括 DMI、sysfs、lspci 和现有设备能力。固定快照有 26 个 hw 命令，覆盖 GPU、显示器、触摸、摄像头、机型和状态组合。

探测也可能有副作用¶

独显可能处于 runtime suspend；某些查询会为了读取设备而唤醒 GPU，增加耗电。通用 NVIDIA detector 优先读取缓存的 sysfs vendor/class，避免“只是问一下有没有 NVIDIA”就唤醒它。

这说明 detector 的质量不只看准确率，还要看观察成本。

NVIDIA 是能力分叉，不是单一包名¶

NVIDIA 安装脚本要决定：

GPU/驱动分支是否支持 GSP；
选择当前 driver 还是 580xx 等兼容分支；
安装匹配 kernel headers；
配置 early KMS / initramfs；
hybrid GPU 状态如何处理。

这些动作有顺序和 reboot 语义，不能简化为 pacman -S nvidia。探测命令提供事实，安装脚本负责把事实收敛成 package 与 boot state。

Intel 与 OEM workaround¶

Intel 路径涵盖 video acceleration、SOF firmware、thermald、LPMD、Wi-Fi 7 与 Panther Lake kernel/camera；OEM/机型路径覆盖 Framework、Surface、ASUS ROG/ExpertBook、Dell XPS、Apple T2、Lenovo speaker 等。

每个 workaround 应满足：

gate 足够窄，不误伤其他机器；
已应用时可以再次运行；
package/config 变化可被 update 继续维护；
需要 reboot 时明确表达；
测试至少验证脚本结构与关键判断。

deferred 用户权限¶

部分硬件需要把最终用户加入 input 等 group。安装时如果 owner 尚未知，不能把权限授予一个猜测用户名。apply-hardware 将待授权信息记录下来，owner provisioning 后再完成。

这与总体三阶段安装同构：把需要“用户身份”这一前置条件的副作用延迟到条件成立时。

网络切换¶

网络脚本启用 NetworkManager 时，也会退休 systemd-networkd 并 mask wait-online，避免两个管理器竞争或启动被一个不再使用的 online target 阻塞。

无线 regulatory domain 从 timezone 推导是一个 best-effort 初始值；它不是把地理时区等同于法律位置，而是在自动安装缺少更多输入时给出比全局默认更合理的配置。

扬声器调优是数据驱动案例¶

匹配表决定哪些机器应用哪份 PipeWire filter/config。运行时流程强调故障隔离：

sequenceDiagram
    participant D as 硬件 detector
    participant T as audio tuning
    participant C as 独立 PipeWire client
    participant G as 主音频 graph
    D->>T: model match
    T->>C: 加载调优链
    C->>G: 切换 route/filter
    T->>G: 验证可用 sink
    alt 验证失败
      T->>G: 回滚旧 route
    end

不重启整个 PipeWire，意味着其他音频客户端不因调优尝试被全部打断。UI 音量取 physical sink，而不是可能固定增益的虚拟 filter node。

新增硬件支持的检查表¶

detector 能否用廉价稳定的 sysfs/DMI 信息？
gate 是否只覆盖目标 revision/model？
脚本第二次运行会发生什么？
包变更和配置变更哪一个先？
initramfs/bootloader 是否需要刷新？
deferred 安装时用户名是否已知？
失败能否回滚，至少能否保持设备原状态？
是否需要物理机 acceptance，而非只做 shell test？

关键源码索引¶

bin/omarchy-apply-hardware — 权限、参数与总入口
install/hardware/all.sh — 确定性动作顺序
bin/omarchy-hw-nvidia — 低副作用 GPU 探测
install/hardware/nvidia.sh — 驱动、headers 与 KMS
install/hardware/intel/video-acceleration.sh — Intel VAAPI
install/hardware/network.sh — NetworkManager 收敛
install/hardware/speaker-tuning.sh — 数据驱动音频适配
docs/audio-tuning.md — client 隔离与回滚

下一章集中看横跨所有阶段的防线与恢复点：15 · 安全边界与恢复。