今日重点：✍️ 写作——今天凌晨 linux-media 收到一份少见的 BUG 报告： ASUS Zenbook A16 + Snapdragon X2 Elite 平台上，ffmpeg 的 V4L2 解码器跑一帧就死。 作者 Christian Cortner 开篇就坦白「我不是内核开发者」，靠 AI 助手追出 5 个驱动问题、 写成 5 段短文。6 小时 22 分后，维护者 Bryan O'Donoghue 主动回复： 「把代码贴出来，我们帮你收尾」。这份报告每一段的写法都值得学——它把维护者的判断成本压到了最低。

✍️ 写作：开篇段 · 一段写完环境/症状/路线图

/ section

〔10-27 00:09 北京〕· Christian Cortner · linux-media · 原文

On an ASUS Zenbook A16 (UX3607OA, Snapdragon X2 Elite / glymur), ffmpeg's h264_v4l2m2m decoder outputs one corrupted frame and stops, on every stream I tried. GStreamer's V4L2 decoders work. Below are the two driver behaviours behind it (1 and 2), two more that stop ffmpeg at a resolution change in the middle of a stream (3 and 4), and an inconsistent CAPTURE format that ffmpeg happens to avoid (5).

I'm not a kernel developer. I tracked this down with an AI coding assistant (Claude, by Anthropic): it traced the driver, wrote a small V4L2 test client and tried changes to the driver. Everything below was run on this laptop, and each local change described made its problem go away here. I can't review or defend kernel patches myself, so I'm reporting the problems instead of sending fixes, but I'm glad to test patches on this machine.

两段话，不到 200 词，但已经回答了维护者脑海里的全部前置问题：在什么硬件上？什么症状？影响多广？你是谁？数据可信吗？你能帮什么忙？下面把这份报告拆成五个可复用的写作动作。

动作①：Subject 把整条线索塞进一行

/ column

★ 标签 + 子系统 + 触发条件 + 症状 + 平台，五件套

Subject 行 · 不写「bug in iris」这种一行谜语

原句 [BUG] media: iris: resolution change handling stops ffmpeg's h264_v4l2m2m decoder on glymur
拆解 [BUG]=这不是补丁，别走 review 流程 ｜ media: iris:=子系统+驱动 ｜ resolution change handling=触发条件 ｜ stops ffmpeg's h264_v4l2m2m decoder=可观察症状（精确到具体客户端的具体组件，不写「broken」）｜ on glymur=平台代号
为什么有效 维护者扫邮件列表时只能看 subject 决定打不打开。这条 subject 等于把「我要不要读」的判断题直接给答案——影响 ffmpeg 主路径 + 在 glymur 上，相关 maintainer 自然会点开。
和你相关 和你相关：写任何 issue / bug report / 工单标题时，把「环境 + 触发 + 症状」塞进一行，比「XX 不工作」省掉维护者两轮追问。

🔗 原文

动作②：披露段 · 坦白身份、说清边界、提供帮助

/ column

★ 「我不是内核开发者」不但不扣分，反而是加分项

披露段 · 4 句

原句 I'm not a kernel developer. ... I can't review or defend kernel patches myself, so I'm reporting the problems instead of sending fixes, but I'm glad to test patches on this machine.
拆解 第一句坦白身份——别装，维护者从行文就看得出；第二句披露 AI 协作（2026 年起社区要求，见 Documentation/process/generated-content.rst）；第三句划能力边界——「我不能 review 也不能 defend」；第四句提供帮助——「但我可以在这台机器上测补丁」。
为什么有效 维护者最怕的是收到一份「看起来是补丁但需要我重做」的贡献。坦白身份+划清边界后，维护者立刻知道这份报告的「可用粒度」：是问题定位而不是补丁，可以直接基于它写修法。
和你相关 和你相关：用 AI 辅助调试后向上游报告时，按这个格式披露——身份+用了什么 AI+数据在哪验证的+你能做什么。坦诚比装专家更能让维护者配合。

🔗 原文

动作③：环境段 · 精确到哈希、版本、补丁栈

/ column

★ 不写「最新内核」，写「tree 在哪个 commit」

Setup 段 · 数据可复现的最低要求

原句 Setup: the linux-msm laptops tree at 65f4ae7320b8 (v7.3-rc7), ... Firmware: video-firmware 3.6 (aeb98f00ce9f) from the Windows driver package. ffmpeg 8.1.3, GStreamer 1.28.8.
拆解 内核 tree 写到 commit 短哈希（65f4ae7320b8）+ 最近 tag（v7.3-rc7）；固件写到版本号 + 固件 blob 的哈希（aeb98f00ce9f）；用户空间组件写到小版本（ffmpeg 8.1.3）。还交代了「叠加了哪些补丁」—— Iris 的 5 个前置补丁一一列出。
为什么有效 「最新内核」「昨天拉的代码」这种话等于没说——维护者无法重现。精确到哈希后，任何人都能 checkout 到同一棵树验证。这是「可复现」的最低门槛。
和你相关 和你相关：给同事/上游报 bug 时，把「我用的是 mainline 最新」改成「我在 git rev-parse HEAD 输出 abc123」，可复现性立刻从 0 拉到 1。

🔗 原文

动作④：问题段 · 症状→机制→数字→修法 四拍

/ column

★ 每个问题独立成段，一段一个 bug

问题 5（最短）· 4 句话说清一个 bug

原句 Setting the OUTPUT format updates the CAPTURE width and height (8aadfd445373) but not bytesperline and sizeimage, which keep their 320x240 defaults on a new instance. For a 640x360 stream, G_FMT(CAPTURE) then reports 640x384 NV12 with a sizeimage of 147456, and iris_vb2_buf_prepare() rejects CAPTURE buffers smaller than 368640 bytes... Recomputing both fields as S_FMT(CAPTURE) does fixed it here.
拆解 第 1 拍·机制：S_FMT 改了什么没改什么，连相关 commit（8aadfd445373）都引上；第 2 拍·数字：640x360 流被报告成 640x384、sizeimage 147456、驱动拒绝小于 368640 的 buffer——具体数字，不是「大小不对」；第 3 拍·谁不受影响：ffmpeg 自己 set 格式所以没事（划范围）；第 4 拍·修法：一句话说完本地怎么修的。
为什么有效 维护者读完一段就能独立判断这一个 bug：是真的吗？严重吗？修法合理吗？可以单独处理、单独回复——5 段拆 5 个 bug 比揉成一坨的「长叙述」好用十倍。
和你相关 和你相关：报多个 bug 时拆开写。每段格式 = 一句机制 + 一组数字 + 一句修法。模糊词（「很大」「经常」「似乎」）一律替换成具体值。

🔗 原文

动作⑤：不收尾——问题说完就停

/ column

★ 没有 Thanks 段、没有 Looking forward、没有敬语

整份邮件的结尾就是问题 5 的最后一句

原句 邮件正文在第 5 个问题的「Recomputing both fields as S_FMT(CAPTURE) does fixed it here.」这一句直接结束，下面是签名和分隔符，没有收尾段。
拆解 技术邮件不是求职信。不要在结尾写「感谢您的时间」「期待您的反馈」「如有需要请告诉我」——维护者每天扫几百封邮件，结束语是噪音。
为什么有效 收尾客话只增加扫读成本，不带任何信息。这份报告的最后一句是修法——读完最后一个字，维护者已经知道该怎么动手。
和你相关 和你相关：技术邮件结尾砍掉客套话。如果一定要写点什么，写「需要更多日志请告诉我」——把对方的下一步明确出来。

🔗 原文

📮 6 小时 22 分后，维护者回了什么

/ section

〔10-27 06:31 北京〕· Bryan O'Donoghue（bod@kernel.org）· linux-media · 原文

Err thanks for the bug report but, if you have a test-case and a resolution - even of the code sucks and/or you don't understand it, please post the code.

One of us can take up the task of finishing it off.

After all we are burning down the rainforest for this stuff so no sense in wasting the already spent compute time and power.

维护者没有因为「AI 辅助」「非内核开发者」推开这份报告，反而主动让他把代码贴出来——即使代码烂、即使作者不懂。 第二句更直接：One of us can take up the task of finishing it off——「我们中有人会接手把它做完」。 最后一句是个黑色幽默：AI 算力已经烧掉了（烧了雨林），就别浪费已经产出的调试成果。 这是 2026 年内核社区对 AI 辅助贡献的真实态度样本——问题定位做得扎实，社区就愿意接手收尾。

✨ 辅助彩蛋 · 术语卡

/ section

★ DRC（Dynamic Resolution Change，动态分辨率切换）

dev-decoder.rst 定义的 V4L2 解码器机制 · 原邮件问题 1/2/3/4 全是它

原文 The note in step 3 of the Initialization sequence says: "If the values configured by the client do not match those parsed by the decoder, a Dynamic Resolution Change will be triggered to reconfigure them."
中文 动态分辨率切换——视频流中途改了分辨率（比如从 640x360 切到 1280x720），解码器不能简单继续按老格式解码，需要走一套协商流程：解码器发 source-change 事件 → 客户端停 CAPTURE → 重新协商格式 → 重启流。这是 V4L2 stateful decoder 规范（dev-decoder.rst）的核心机制。
记忆钩子 DRC 的「Dynamic」指的是流进行中变，不是用户手动改。理解成「视频流的热插拔」——分辨率变了，整条管线得重新协商。
和你相关 和你相关：调 V4L2 stateful decoder（iris / venus / mtk-vcodec / hantro）就一定会碰到 DRC；它的协商时序是解码器 bug 的高发区。读懂这份报告的 4 个 DRC 相关问题，等于预习了所有 stateful decoder 的共同坑。

🔗 原文

✍️ 今日练习

/ column
✍️ 读后仿写：假设你在调试一个 ISP 驱动——在 Qualcomm SM8550 开发板上，v4l2-ctl --stream-mmap 每次只能抓到一帧就卡住，但 GStreamer 的 v4l2src 能正常出流。你怀疑 3 个子问题（buffer 排队逻辑、格式协商、中断处理）。请按今天学到的「开篇一段」结构写一段英文开篇：① 硬件 + 板型 ② 症状 + 复现率 ③ 对照（谁工作）④ 路线图（下面有 N 个问题）。不超过 4 句。
💡 显示答案
参考（仿写示范，非原文）：On a Qualcomm SM8550 development board (MTP, Linux v6.12-rc3), v4l2-ctl --stream-mmap captures one frame and then blocks indefinitely, on every sensor I tried. GStreamer's v4l2src element streams without issues on the same hardware. Below are the two driver behaviours I suspect are behind it (1 and 2), and one inconsistency in the format negotiation path that v4l2-ctl happens to hit but GStreamer does not (3).
📖 原文：On an ASUS Zenbook A16 (UX3607OA, Snapdragon X2 Elite / glymur), ffmpeg's h264_v4l2m2m decoder outputs one corrupted frame and stops, on every stream I tried. GStreamer's V4L2 decoders work. Below are the two driver behaviours behind it (1 and 2), two more that stop ffmpeg at a resolution change in the middle of a stream (3 and 4), and an inconsistent CAPTURE format that ffmpeg happens to avoid (5).
📎 原文引用

Write the bug report you would want to receive — hardware, symptom, roadmap, disclosure, numbers, fix.

素材：lore.kernel.org linux-media · iris glymur BUG 报告（Christian Cortner 〔10-27 00:09 北京〕+ Bryan O'Donoghue 〔06:31 北京〕）· 内核英语 · 每日一篇