在 Amlogic S922X / G12B（飞牛 OES Plus 等）设备上，把闲置的 3D 与硬件解码 能力点亮并接入安卓容器，并提供一个可观测、可一键修补的 Web 控制台。
本项目所有结论均来自真机实测，包括那些"不好看"的结论 —— 请看 第 6 节：弊端与局限。
本仓库只发布三样东西：
| 内容 | 路径 | 说明 |
|---|---|---|
| GPU 控制台源码 | gpu-console/ |
飞牛 fnOS 原生应用（FPK）完整工程，Python 3 单文件后端 + 前端 + 修补脚本 |
| FPK 安装包 | release/gpuconsole_1.3.10.fpk |
可直接安装到飞牛设备的成品包（最新版；release/ 下保留历史版本） |
| 部分测试数据 | docs/ |
19 篇真机实测报告，已脱敏 |
这台设备出厂时 GPU（Mali-G52）和 VDEC 硬件解码器在系统里是"沉睡"的： 安卓容器跑在软件渲染上，视频播放走纯 CPU 软解，CPU 长期高负载。
本项目做了三件事：
- 点亮宿主 GPU —— 编译并加载主线
panfrost驱动，屏蔽冲突的闭源mali_kbase， 得到/dev/dri/renderD128，让安卓容器从 SwiftShader 软渲染切换到硬件渲染。 - 把硬件解码器接到安卓媒体栈 —— 自研一个 OMX IL 插件，把 Linux 内核
meson-vdec（V4L2 stateful M2M）包装成 Android 能识别的OMX.meson.h264.decoder，让 App 的MediaCodec能透明地用上硬解。 - 做控制台 —— 一个飞牛 fnOS 原生应用（FPK），实时观测 GPU/硬解状态， 20 项硬件体检，问题可一键修补。
定位：这是一个个人硬件适配工程，不是通用产品。它高度绑定特定 SoC、 特定内核、特定安卓容器镜像。
| 项目 | 切换前 | 切换后 |
|---|---|---|
| 容器渲染器 | SwiftShader（软件） | Mesa Mali-G52 (Panfrost) |
| 中断线 | 无 | panfrost-job 正常触发 |
这是本项目最实在、最无争议的收益：UI 合成、游戏、WebGL 全部走 GPU， CPU 从满负荷的像素搬运中解脱。
🔄 本节已于 2026-10-08 修正。 此前写的「硬解比软解贵 60%」只测了 容器内 OMX 播放这一条链路，并不代表硬件解码本身。分两层看：
| 分辨率 | 硬解 | 硬解 CPU | 软解 → NV12 | 软解 CPU | 硬解省 CPU |
|---|---|---|---|---|---|
| 1080p | 132 fps | 0.86 核 | 120.8 fps | 4.10 核 | 4.8× |
| 720p | 231 fps | 0.77 核 | 255.9 fps | 4.05 核 | 5.3× |
| 4K | ≈36 fps | 0.05 ~ 0.07 核 | 32.9 fps | 4.49 核 | 近乎全部 |
- 吞吐与软解基本打平（±10%）；1080p 前 40 帧与软解 逐字节相同（无损）。
- 6 核同级满载下仍是 132~133 fps，与空载完全一致 ⇒ 硬解吞吐不受负载影响。
⚠️ 此前报告里的「1080p 双模态 40 / 118 fps」是测量工具假象（见 6.1），已作废；真实值恒定 132 fps。- 完整口径见
docs/AV编解码可用性报告_2026-10-08.md第八节。
| 场景 | 硬解 | 软解 |
|---|---|---|
| 真实播放器，720p@25 | 1.39 ~ 1.49 核 | 0.86 ~ 0.88 核 |
原因不在硬件：插件为了绕开容器 gralloc 缺陷（AHardwareBuffer_lock 恒返回 -38）
回答了 RequiresSwRenderer=1，框架因此放弃 Surface 零拷贝，改走 ByteBuffer + 软件渲染器 ——
NV12 要搬两次、V4L2 syscall 开销重、最后还要软件做 YUV→RGB，
解码省下的算力被搬运吃光并倒挂。详见 6.1。
一句话：硬解本身是省 CPU 的（4~5×）；当前「不省」是容器渲染路径的架构问题， 不是硬件问题。修好容器 gralloc / 打通 Surface 零拷贝后，这条负收益有望翻正。 控制台内置的一键软/硬解切换（v1.1.0）可让你按实际场景选择。
| 功能 | 说明 |
|---|---|
| 实时状态 | 3D 负载（用中断增长率代理）、硬解负载、GPU 频率、CMA 连续内存、温度、驱动模块 |
| 安卓容器面板 | 渲染模式（host/guest）、实际渲染器、设备节点、OMX 插件一致性 |
| 20+ 项硬件体检 | 宿主 H1–H10 + 容器 C1–C10 + 风险 R1 + 自愈 S1–S2，逐项给出问题与修法，并打分 |
| 一键修补 | 容器层（注入插件/修权限）、宿主层（modprobe/udev/自愈任务/自启动） |
| 常驻自愈 | cron 每分钟：插件注入、权限硬化、mediaserver codec 缓存刷新；另配完整性守卫，主脚本被断电截断时自动从备份恢复 |
| 一键切 GPU 直通 | 改 compose 并重建容器（会中断服务） |
| 软/硬解切换 | v1.1.0 新增，附实测数据说明 |
| 一键授权（免 SSH） | v1.3.6 新增：用应用的 Docker 权限按与 grant_root.sh 完全相同的安全边界自动完成 root 授权，无需手动 SSH |
| 命令行查询 | gpu_status.sh 可在 SSH 直接用，不依赖 Web |
界面采用 fnOS 2.0+ 深色主题，中文。
v1.3.6 起后端接口全面加固：20+ 项硬件体检改为后台任务 + 前端轮询， 不再有穿越飞牛 nginx 网关的长请求（此前体检完成后的自动复检必现
Failed to fetch）； 所有幂等请求带网络层自动重试，瞬时抖动不再弹「读不到监控数据」。 同时新增免 SSH 一键授权，新设备装完即可解锁宿主层修补按钮。v1.3.7：修复授权后「重载补丁模块 / AVE 一键修复」仍报部署物缺失的问题 —— 授权固化此前只复制了修补脚本本体、没带
scripts/deploy/，而修补脚本跑在 root 目录时 取不到包内部署物；现在授权会把deploy/一并固化，脚本还会兜底从应用安装目录取件， 失败信息也能直接分辨「部署物未找到 / 缺文件 / 内核 vermagic 不匹配」。root 授权引导框 移到页面最顶部，授权成功后自动消失。
飞牛内核里带一套 Amlogic AVE H.264 硬件编码器（encoder.ko + libvpcodec，设备节点
/dev/amvenc_avc）。v1.3.4 起控制台把它做成了可观测 + 可一键修复的面板；
v1.3.5 起修复所需部署物随包内置，全新安装开箱即用；v1.3.7 起授权固化也会一并带上 deploy/，授权后修补同样开箱可用。
实测（Amlogic S922X / G12B，6 核，avetest10 纯编码计时）：
| 分辨率 | 吞吐 | CPU 占用 |
|---|---|---|
| 640×360 | 125.2 fps | ≈0.16 核 |
| 1280×720 | 34.5 fps | ≈0.16 核 |
| 1920×1080（fps 配置 25） | 15.9 fps | ≈0.18 核 |
| 1920×1080（fps 配置 60） | 29.9 fps | ≈0.14 核 |
- CPU 仅 0.14–0.18 核 —— 这是硬编相对软编（x264 同档约 2.6 核）的核心优势：几乎不占 CPU。
- 分辨率上限 1080p；编码流程可稳定跑完，零挂死。
- 输出为标准 Annex-B H.264（Main profile），ffmpeg 可直接解码。
完整口径与全部实测数据见
docs/AV编解码可用性报告_2026-10-08.md。
- 拥有 Amlogic G12 系列（S922X / S905X3 等）的飞牛 NAS，想让安卓容器用上 GPU
- 想搞清楚自己设备上 GPU / VDEC 到底有没有在工作（可观测性）
- 愿意读日志、看数据、接受"实测可能推翻预期"的折腾型用户
- 需要把硬解能力接进安卓媒体栈做进一步开发（插件源码可直接复用）
- 非 Amlogic 平台：控制台会自动降级，硬解插件完全不适用
- 想直接"装了就省 CPU"：宿主侧硬解确实省 CPU 4~5×，但容器内播放这条链路 走硬解仍是负收益（受容器渲染路径限制），需要你自己切换权衡
- 生产环境 / 不能承受宕机：本项目涉及 modprobe、容器重建、DTB 改动， 且设备没有硬件看门狗，出错需物理断电
- 期待长期维护：单人项目，见 6.6
# 0) 获取源码（或直接下载 Release 里的 fpk，可跳过 1)
git clone https://github.com/wangbujiangwude/oesp-gpu-console.git
# 1) 打包（在 gpu-console 目录）
cd oesp-gpu-console/gpu-console && bash build_fpk.sh
# → ../gpuconsole_<版本>.fpk
# 2) 在飞牛设备上安装
appcenter-cli install-fpk gpuconsole_1.3.10.fpk -v 1
# 注意：同 appname 不会升级，需先 uninstall 再 install
# ⛔ uninstall 子命令不接受 -v 参数（写了只打印 Usage，看起来安装成功实则未替换文件）
# 3) （可选，v1.3.6 起可不做）授予宿主层修补所需的 root 权限，只需跑一次
# 方式一：在面板点「一键授权（免 SSH）」，无需终端
# 方式二：SSH 里执行
sudo bash /var/apps/gpuconsole/target/scripts/grant_root.sh打开飞牛桌面 → GPU 控制台即可。
⚠️ 不要用appcenter-cli restart（该子命令不存在），用stop+start。
插件源码不在本仓库。 控制台自带预编译的 32 位产物
gpu-console/scripts/libstagefrighthw32.so，安装 FPK 后即位于设备上的/var/apps/gpuconsole/target/scripts/，控制台的「注入硬解插件」按钮直接取用它。 也就是说：你不需要编译任何东西，除非要改插件行为。
若确实需要自行构建（例如适配别的平台），流程如下 —— 但这部分源码需另行获取， 本仓库不提供：
# 1) 准备 Android NDK r26d（约 2 GB）
# https://developer.android.com/ndk/downloads
# 2) 编译（源码目录结构：build_omx.sh + meson_omx_plugin.cpp + meson_vdec.h）
bash build_omx.sh
# → out/libstagefrighthw32.so ★ 实际部署用这个（HAL 进程是 32 位）
# → out/libstagefrighthw.so （64 位，仅参考）
# 3) 注入安卓容器
docker cp out/libstagefrighthw32.so <容器名>:/vendor/lib/libstagefrighthw.so
docker exec <容器名> chmod 644 /vendor/lib/libstagefrighthw.so
# 4) ★ 必须重启 mediaserver（它会缓存 MediaCodecList，只重启 media.codec 无效）验证是否真的走了硬解（这是唯一可靠判据）：
# 宿主上读 vdec 中断，播放期间应增长（真硬解约 23~25 次/秒，为 0 即未走硬解）
awk '$NF=="vdec"{c=0; for(i=2;i<=7;i++) c+=$i; print c}' /proc/interrupts| 依赖 | 要求 |
|---|---|
| 硬件 | Amlogic G12 系列（本仓库实测于 S922X / G12B） |
| 系统 | 飞牛 fnOS ≥ 1.1.8 |
| 内核 | Linux 6.x + meson-vdec 模块可加载 |
| 容器 | Docker + redroid 12（安卓容器） |
| 控制台 | Python 3（仅标准库，无 pip 依赖） |
| 插件编译 | Android NDK r26d —— 仅当你需要重新构建插件时（默认用随包二进制即可） |
┌────────────────────────────────────────────────────────────────┐
│ 飞牛桌面 / nginx │
│ /app/gpuconsole/* ──── Unix Socket ────┐ │
└───────────────────────────────────────────┼────────────────────┘
▼
┌────────────────────────────────────────────────────────────────┐
│ gpu-console/server/gateway.py （单文件：HTTP 服务 + 前端 + 采集）│
│ /api/status /api/detect /api/repair /api/decoder /api/android │
└──────────┬──────────────────────────────────┬─────────────────┘
│ sudo -n（经 grant_root 最小授权） │ docker exec / cp
▼ ▼
┌──────────────────────────┐ ┌──────────────────────────────────┐
│ scripts/oesp_gpu_fix.sh │ │ 安卓容器 androidemu-android │
│ 20 项检测 + 精准修补 │ │ MediaCodec → ACodec → OMX HAL │
│ modprobe / udev / chmod │ │ media.codec（★ 32 位进程） │
│ --decoder soft|hard │ │ ↓ dlopen │
└──────────────────────────┘ │ /vendor/lib/libstagefrighthw.so │
└──────────────┬───────────────────┘
│ V4L2 ioctl
┌─────────────────────────────────────────────▼──────────────────┐
│ 宿主内核 meson-vdec → /dev/video0 │
│ （依赖闭源 amlogic_codec_mm / media_clock / firmware 等模块） │
└─────────────────────────────────────────────────────────────────┘
| 决策 | 原因 |
|---|---|
回答 RequiresSwRenderer=1 |
不回答时框架强制走 ANW/Surface，而容器 gralloc 的 AHardwareBuffer_lock 恒返回 -38，Surface 方案彻底不可用。回答后框架改用 ByteBuffer + 自带软件渲染器 —— 这是硬解能跑通的前提，也是「容器内播放负收益」的根源（注意：硬件解码器本身是省 CPU 的，见 2.2 / 6.1） |
| 必须产出 32 位库 | 本机 media.codec（OMX HAL service）是 32 位进程，64 位库会被忽略 |
flock 用户态会话互斥 |
驱动只允许一个活跃会话（cur_sess 判据）。并发两个会话会触发固件死锁（见 6.4） |
| 内部 4 帧溢出环 | 让 CAPTURE 出帧与 App 供缓冲速度解耦，否则 App 落后 → 队列满 → 固件丢帧 |
不读 /sys/class/vdec/*、不开 /dev/video26 |
会导致整机死锁，见 6.3 |
这一节是本项目最重要的部分。以下每一条都有实测依据，没有一条是谦虚客套。
🔄 本节标题与结论已于 2026-10-08 修正。 原文写「硬解在当前架构下是负收益」， 那是把容器渲染路径的开销误记在了硬件解码头上。实测应分两层。
宿主 V4L2 meson-vdec 解码、输出 NV12，与 ffmpeg 软解同工作形态对照：
| 分辨率 | 硬解 CPU | 软解 CPU | 硬解省 CPU | 吞吐对比 |
|---|---|---|---|---|
| 1080p | 0.86 核（132 fps） | 4.10 核（120.8 fps） | 4.8× | 打平（+9%） |
| 720p | 0.77 核（231 fps） | 4.05 核（255.9 fps） | 5.3× | 打平（−10%） |
| 4K | 0.05~0.07 核（≈36 fps） | 4.49 核（32.9 fps） | 近乎全部 | 打平（+10%） |
- 质量：1080p 前 40 帧与软解逐字节相同（Y_MAE = 0）。
- 不受负载影响：6 核同级满载下 132.2
133.1 fps，与空载一致（core 由 0.86 降到 0.550.69）。 - ⇒ 对「多路解码」「硬解 + 软编转码」这类场景，硬解是实打实的正收益： 同 CPU 预算下可跑的解码路数约为软解的 3~5 倍。
| 对照 | 硬解 | 软解 |
|---|---|---|
| 真实播放器，720p@25 | 1.39 ~ 1.49 核 | 0.86 ~ 0.88 核 |
为什么：为了让真实播放器能跑起来，插件回答了 RequiresSwRenderer=1，
框架因此放弃 Surface 零拷贝，改走 ByteBuffer + 软件渲染器。代价是
NV12 数据要搬运两次、V4L2 syscall 开销重（实测 sys 1.5s vs user 0.3s）、
最后还要软件做 YUV→RGB。解码省下的那几核，被搬运与上屏吃光并倒挂。
播放时宿主 sy（内核态）从 13.5% 冲到 31.7% —— 一半以上时间在内核搬运和 syscall。
容器内优化已试过三项，全部无效（有价值的负结果，它缩小了问题范围）：
| 优化项 | 结果 |
|---|---|
grabFrame 逐行 memcpy → 整块拷贝（720p 每帧 1080 次小块拷贝 → 2 次） |
CPU 无变化（1.49 vs 基线 1.50） |
| 零拷贝旁路溢出环（省每帧 1.38 MB 的一次拷贝） | CPU 无变化（1.48 / 1.39） |
| 主循环忙轮询 → 阻塞等待 | 直接卡死，只出 3 帧后解码线程停摆 |
memcpy 优化零收益说明插件内的搬运不是瓶颈；真正的开销在更下层 （V4L2 缓冲在内核态的 cache 同步 / syscall）—— 架构性的，用户态改不掉。
补充两个容易误读的数据： ① 用
mctest（ByteBuffer 基准）测时硬解 CPU 反而省 41~46%（720p：0.72s vs 1.22s） —— 那更接近「第一层」的真实能力； ② 早前报告里的「硬解双模态 40 / 118 fps」是测量工具假象：vdec-dec在固件 偶发少吐 1 帧时，退出等待从 150 ms 回退到 5 s 固定等待，把墙钟拉长 3×、算出的 fps 被腰斩。该结论已作废 —— 真实速率恒定 132 fps（1080p），见docs/AV编解码可用性报告_2026-10-08.md第八节。
要让「容器内播放」也翻正，只有两条路：
- Surface 零拷贝（社区
meson-vdec路线）—— 卡在容器 gralloc 的-38，成本高； - 换用厂商
amvdec_ports栈（2026-10-05 新增）—— 它自带bypass_vpp/bypass_ge2d/enable_drm_mode参数，帧走 VDEC → VPP → ge2d → DRM dma-buf， CPU 全程不碰像素，正是电视盒子的做法。障碍是/dev/video26open 死锁（雷区 #1）。
本节此前写的「HEVC / AV1 硬件不存在」是错的，特此更正。 那个结论来自社区驱动
meson-vdec的VIDIOC_ENUM_FMT，它只反映社区驱动实现了什么， 不反映硬件有什么。详见docs/厂商解码栈开盖报告_2026-10-05.md。
meson-vdec（社区驱动）的 VIDIOC_ENUM_FMT 实测：
| 格式 | 社区 meson-vdec |
硬件真实能力（厂商栈） |
|---|---|---|
| H.264 | ✅ 已打通 | ✅ amvdec_mh264 |
| VP9 / MPEG1 / MPEG2 | ✅ amvdec_vp9 / amvdec_mmpeg12 |
|
| HEVC / H.265 | ⛔ 社区驱动未实现 | ✅ amvdec_h265 存在，未启用 |
| AV1 | ⛔ 社区驱动未实现 | ✅ amvdec_av1 存在，未启用 |
| AVS2 / AVS3 / VC1 / MPEG4 / MJPEG / H.266 | ⛔ 未实现 | ✅ 模块齐备，均未启用 |
更正后的事实：飞牛系统内已内置 61 个 Amlogic 厂商驱动模块
（/lib/modules/$(uname -r)/updates/trim/amlogic-gx-vendor-drivers/），
vermagic 与当前内核完全一致，其中 45 个格式/加速模块从未被加载。
微码 /lib/firmware/video/video_ucode.bin（1.6 MB）里内嵌了
g12a_hevc.bin、av1_mmu、g12a_avs2_mmu.bin、gxl_mpeg12_multi.bin 等全部格式固件。
所以「HEVC 走不了硬解」不是硬件天花板，是「厂商栈没启用 + 我们一直在用社区驱动」。
此前实测 HEVC 播放 vdec 中断为 0，是因为走的是 meson-vdec（vdec 中断线），
而厂商栈用的是另一套中断与内存路径。
为什么厂商栈没启用：飞牛官方在 /etc/modules-load.d/meson-vdec.conf 里写明
# meson-vdec # 禁用: 帧回传会挂死驱动，并选择只启用 galcore。
厂商栈的 V4L2 入口 /dev/video26（aml-vcodec-dec）open 即整机死锁，
列入本项目五条致命雷区之首。这是当前唯一挡在厂商栈前面的障碍。
另有两类 App 即使对 H.264 也用不上硬解：
- 抖音：使用自研
libttffmpeg，不走MediaCodec→ 劫持对它们无效 - Chromium / VIA 浏览器：主动选择
OMX.google.*，需要插件额外声明COLOR_FormatSurface（未做）
设备没有硬件看门狗，以下操作会让内核立即死锁，只能物理断电：
| # | 禁止操作 | 备注 |
|---|---|---|
| 1 | open() /dev/video26 |
闭源 aml-vcodec-dec 固件死锁 |
| 2 | 读 /sys/class/vdec/* 任意节点 |
哪怕只是 cat |
| 3 | ffmpeg -c:v h264_v4l2m2m 与软编混用 |
— |
| 4 | 运行时 rmmod 闭源 GPU 驱动 |
— |
| 5 | 并发创建两个 VDEC 会话 | 2026-10-04 实测触发死锁，导致一次断电 |
控制台与修补脚本已主动规避上述路径。若你要改代码，请阅读 CONTRIBUTING.md 第 1 节。
| 缺陷 | 影响 | 状态 |
|---|---|---|
| VDEC 会话引用计数只增不减 | 每次解码 +1，只能靠杀 media.codec 回收。实测 10 次会话 ref 3→13，但不占内存、不影响解码正确性（CMA 无泄漏），所以判定为无害计数器 |
已知，不修（重启进程即可回收） |
SendCommand 中 cmdThread.join() 同步死等 |
播放器 stop / 切换视频时会报 failed to flush (err=-110) 并重启一次解码组件 |
未修（修法明确：改成单 worker + 命令队列） |
改 media_codecs.xml 切不到软解 |
实测改 name 或 type 后框架仍选中 meson 组件，必须移走 .so | 已知（控制台已用移走 .so 的正确方式） |
| 安卓容器升级会回退 GPU 直通 | 升级用包内模板覆盖 compose，redroid_gpu_mode 从 host 变回 guest，静默退回软渲染 |
需手动重跑修补 |
| 断电可能把文件截成 0 字节 | 2026-10-04 断电后自愈脚本被截断成空文件，cron 每分钟静默执行空脚本，所有自愈能力失效且无任何日志 | 已加完整性守卫 |
| CMA 长期偏低是正常现象 | 总 1204 MB（896+308），空闲常在 13~188 MB 波动。这不是泄漏，是内核 movable 页借用；实测 1080p 在空闲 65 MB 时仍能正常解码 | 非缺陷，勿误判 |
| VPU / ge2d 闲置 | VPU 有驱动节点但闲置；ge2d 无 DT 节点不 probe | 未处理 |
- 强绑定硬件：仅验证于 Amlogic S922X / G12B。其它平台控制台会自动降级， 硬解插件完全不可用。
- 依赖闭源内核模块：运行期依赖厂商的
amlogic_codec_mm、media_clock、firmware等。这些不属于本项目、不随本项目分发，也可能随系统更新变化。 - 依赖非标准安卓容器：redroid 12 + privileged 模式。
- 构建需 2 GB 的 NDK，且需手动下载（仓库不含）。
- fnOS 应用环境限制：
sys.executable为空串、PATH 不全（无/usr/sbin）、install_callback以应用用户而非 root 运行 —— 控制台已全部绕开，但这些 限制意味着换一个 fnOS 版本可能就要重新适配。 - 容器重建风险：切 GPU 直通会重建安卓容器，服务中断数分钟。
- 单人项目，2026-09-29 ~ 2026-10-04 密集开发约一周，此后节奏不稳定。
- 没有自动化测试、没有 CI。所有验证靠真机手工跑。
- 大量参数（预热帧数、缓冲数量、超时）是针对这台设备调出来的经验值， 换设备大概率需要重调。
- 部分代码是"能跑就行"的探索性产物，代码质量参差，注释里记录了大量 踩坑过程而非整洁的设计说明。
- 技术报告中包含若干已被推翻的早期结论（例如曾误判"CMA 被容器占满"、
曾认为"并发测试无害"）。这些保留在
docs/中作为过程记录， 请以最新结论和代码注释为准。
- 仓库为纯 MIT（见第 7 节），无 GPL 传染风险。
- 本项目不含任何反编译/逆向得到的闭源代码。对闭源驱动的分析结论全部来自
只读元信息（
modinfo、strings、文件清单）与公开文档。 - 涉及
modprobe、容器重建、DTB/overlay 改动，使用者需自行承担设备风险。
MIT（见 LICENSE），可以放心商用、修改、再分发。
相关说明见 NOTICE：
- 构建期用到的
tools/aosp-headers/（AOSP 头文件为 Apache-2.0， Khronos OpenMAX IL 头文件为 MIT 风格）与 MIT 兼容，仅用于接口声明。 - Android NDK 不随仓库分发，需自行下载。
- 开发期曾参考 Linux 内核 meson-vdec 驱动源码（GPL-2.0+，BayLibre SAS）， 为保持本仓库纯 MIT，该参考代码不随本仓库分发，本项目也不依赖它的任何一行。
docs/ 下收录 19 篇真机实测报告（已脱敏，仅保留与控制台功能与结论相关的部分），
索引见 docs/README.md。推荐入口：
- 想看最新性能真相（含 2026-10-08 硬解口径修正）→
docs/AV编解码可用性报告_2026-10-08.md - 想看硬解优化失败史 →
docs/硬解优化与软硬解切换_2026-10-04.md - 想知道硬解为什么不省电（注意：指的是容器内播放路径，非解码器本身）→
docs/相册硬解失败与CPU实测_2026-10-04.md - 想了解控制台能观测什么 →
docs/GPU能力实测报告.md
⚠️ 这些报告按时间顺序记录了认识不断被修正的过程，存在已被后续实测推翻的 早期结论。冲突时以时间最新者和源码注释为准。另有 14 篇涉及内网拓扑与远程登录细节的报告未收录，以规避个人信息泄露。
另附 PROJECT_INVENTORY.md，是完整的文件清单、
依赖关系与发布取舍说明。
请先阅读 CONTRIBUTING.md —— 尤其是第 1 节的
五条致命红线，它们会让你付出一次物理断电的代价。
本项目最欢迎的贡献是用实测数据推翻本文档中的结论。项目过程中已经发生过多次 （CMA 归因、并发安全性、硬解收益……），这是最有价值的输入。
1.3.10（当前版本）
- 🐛 硬解节点改为按设备名扫描，不再只认
/dev/video0 - 🐛 厂商解码节点判「厂商栈·未启用」，不误标为可用
- 🐛 3D 驱动区分两条路线，仅共存时才判「冲突」
- 🧩
renderD128缺失降为提示项「无 DRM 层」 - 🐛 中断名改候选探测，GPU 退化到
ffe40000.gpu - 🐛 修中断计数误加 GIC 硬件中断号的问题
- 🧩 「为 0」与「本机无此中断」分开显示
- 🐛 无 devfreq 时频率显示「不可读」并禁用档位按钮
- 🐛 CMA 占用 ≥95% 转红告警，≥80% 转黄
- 🧩 部署物按内核版本分目录分发，平铺位换 c1151
1.3.9
- 🐛 升级后仍报部署物缺失：钩子现在刷新固化脚本副本
- 🧩 sudoers 改指固化副本，与一键授权统一路径
- 🧩 取件改多候选逐文件解析，失败时给出补拷命令
- 🐛 修网关双层 sudo 每 6 秒刷一条报错
1.3.8
- 🆕 新增系统更新自愈：内核升级后现场重编部署物
- 🧩
ge2d-regs.h随包携带，供现场重编使用 - 🧩 GE2D 未绑定设备时提示设备树缺节点
1.3.7 / 1.3.6 / 1.3.5
- 🐛 授权与升级一并固化
scripts/deploy/ - 🆕 新增免 SSH 一键授权
- 🧩 硬件体检改后台执行 + 前端轮询
- 🧩
ge2d_oesp.ko、ge2d_selftest等随包内置
1.3.4 / 1.3.3
- 🆕 新增 AVE 硬编码 HCODEC 面板与一键自检
- 🆕 新增 2D 加速 GE2D 面板与 canvas 补丁模块
1.2.0 加载厂商解码格式模块，解锁 HEVC / AV1 / VP9 硬件解码。
1.1.0 首个开源发布，含软硬解切换与 GPU 客户端按进程归因。