在嵌入式 Linux 终端上接入 UVC 模组，V4L2 应用联调是整个链路中承上启下的一环。很多团队把“能出图”当作终点，但真正可交付的成果，应该是一套能支撑后续开发、测试和维护的完整接口与验证体系。
首先，驱动层验证结果应该明确交付。这包括 UVC 模组在目标内核下的枚举信息、支持的格式与分辨率列表、帧率范围，以及带宽和电源管理的实际表现。不要只贴 lsusb 和 v4l2-ctl --list-formats-ext 的输出，要整理成一份兼容性说明，标明哪些参数组合已经实测通过，哪些存在限制，比如 MJPEG 和 YUYV 在不同分辨率下对 CPU 占用和帧率的影响。
其次，应用层接口要清晰可复用。联调不是调通一个 demo 就结束，而应该提炼出 V4L2 的打开、设置格式、申请缓冲区、流开关、异常处理等标准流程，形成可裁剪的代码模块或参考示例。交付物里至少要包括：设备节点的动态识别逻辑、多格式切换的完整路径、帧超时或设备断开的处理策略，以及内存映射或用户指针模式的选择依据。这样后续接 ISP、算法库或显示模块时，不需要再推翻重来。
第三，可执行的测试用例和验收数据缺一不可。除了常规的实时预览、拍照、录一段视频，还要覆盖热插拔、低光照、长时间运行、CPU 占用率波动等场景。测试记录里应写明环境温度、内核版本、模组固件版本，这些信息比单个帧率数字更有说服力。如果调试过程中改过驱动参数或设备树，也要一并附上 diff 和说明，避免现场问题无法复现。
最后，一份简短的联调报告是必要的。它不需要长篇大论，但要把关键决策记录下来：为什么选择某个缓冲区数量，为什么对某个格式降级处理，V4L2 事件订阅和 poll 机制用了哪些。这些内容看似琐碎，却是后续接手的人最需要的东西。真正合格的交付，是让下一个工程师拿到这套资料后，能独立完成移植或问题排查，而不是再把你叫回来问一遍“当时是怎么调的”。