V4L2到DRM：RK3588无库依赖的摄像头显示链路实践

从V4L2到DRM这条链路我最初是在一块RK3588开发板上被逼出来的。当时项目要做一个纯本地显示的工业预览器要求USB摄像头画面实时上MIPI屏幕系统里没有桌面环境没有OpenCV甚至不想装GStreamer。手里能用的就是Linux内核自带的V4L2视频采集框架和DRM显示框架。折腾了大概两个晚上把这条路完整跑通之后我意识到这套“无库依赖”的方案其实非常适合做嵌入式显示底层开发的基础设施——无论你以后接RTSP推流、加AI识别还是做多路拼接最终都绕不开从摄像头读帧、把帧送到屏幕这一步。这篇文章就把我从V4L2采集到DRM上屏的完整过程、关键代码路径和踩过的坑全部记录下来。1. 为什么非要用“裸奔”方案无库依赖背后的真实动机1.1 无库依赖不是炫技是被环境逼出来的很多人第一反应是在RK3588上显示摄像头图像OpenCV一帧imshow不就行了确实在带完整图形栈的Ubuntu桌面环境下这条路是完全成立的。但实际项目中大量RK3588板子出厂的系统是精简版Ubuntu Server、Buildroot或者自己裁剪的固件没有X11/Wayland没有GTK/Qt甚至连/lib/modules下的驱动都只留了必要部分。这种情况下你还去装OpenCV会被依赖树折腾到怀疑人生——libgtk要重编、ffmpeg版本冲突、Python环境不干净一层套一层。另外一个更关键的原因是延迟与可控性。OpenCV的VideoCapture底层虽然也是V4L2但它内部可能在帮你做颜色空间转换、缩放和格式封装中间至少多一两层内存拷贝。而DRM直达VOP2RK3588的显示控制器的方式可以把摄像头那一帧数据直接送到显示plane上整条路径上你完全掌握每一步发生了什么。对于要做工业视觉、医疗设备、仪器仪表这类对实时性敏感的嵌入式项目来说这种可控性比省事重要得多。1.2 V4L2与DRM在链路中的分工简单来说V4L2Video4Linux2是Linux内核里负责视频采集的标准框架摄像头驱动比如UVC驱动把USB控制器收到的数据包装成缓冲区通过ioctl和mmap提供给用户态。DRMDirect Rendering Manager则负责显示侧KMSKernel Mode Setting子系统的核心工作是管理显示控制器、编码器、连接器和图层plane。这两者天然就是同一枚硬币的两面V4L2解决“视频从哪来”DRM解决“图像往哪去”。中间要用一块共享内存把两边接起来也就是帧缓冲区的传递。无库依赖方案的本质就是省掉所有中间层直接用系统调用把这一来一回打通。1.3 这个方案适合谁不适合谁先说适合谁嵌入式Linux初学者想彻底弄懂视频采集与显示原理的做产测工具、工业HMI、车载后装设备这类需要固定硬件环境的开发者还有想为后续优化做底层储备的人——理解裸V4L2和DRM之后你再去看GStreamer的源码或者Rockchip的MPP都会轻松很多。不适合谁要快速出demo的、要处理大量视频格式转换的、需要在多平台间平滑迁移的。这些场景你硬要无库依赖纯粹是给自己挖坑。工具和方案都有适用边界明确这一点比掌握代码本身更重要。2. 数据从摄像头到屏幕的完整路径先画对一张图再动手2.1 RK3588硬件拓扑VOP2、MIPI DSI与USB控制器先看清楚RK3588这侧的硬件结构不然中间定位问题会很痛苦。RK3588的显示链路核心是VOP2它集成了多个视频端口VP0~VP3每个VP可以绑定不同的显示控制器输出。VOP2内部有多个planeplane就是硬件图层每一层可以挂一个framebuffer硬件做alpha混合后统一输出。MIPI DSI作为显示输出接口之一挂在VOP2的某个VP下面外部接MIPI屏幕。USB摄像头则走完全另一条路摄像头通过USB Host控制器接入数据到达内存后由UVC驱动处理。UVC是USB Video Class标准Linux内核的uvcvideo驱动负责把USB的URB数据整理成V4L2的缓冲区队列。这两条链路在内存处交汇——V4L2的缓冲区就是DRM要拿去显示的那块数据只是需要处理好格式和内存类型。2.2 软件视角的九步链路我把整条链路拆成九个步骤调试时心里始终绷着这根弦问题出在哪一环能很快定位打开摄像头设备 /dev/video0查询V4L2能力协商采集格式宽度、高度、像素格式向驱动申请缓冲区MMAP类型驱动直接映射物理内存到用户态把缓冲区排入采集队列启动视频流从队列取出已经填好的帧DQBUF打开DRM设备 /dev/dri/card0获取显示资源ConnectorMIPI屏幕、CRTC、Plane创建DRM Framebuffer把图像数据关联进去通过PageFlip或SetPlane把帧提交到显示控制器第5步到第8步之间是数据交接的关键地带也是后面性能优化的主战场。2.3 一个关键抉择用户态拷贝还是DMA-BUF引用到了第6、7步你会发现一个岔路口V4L2返回的缓冲区怎么交给DRM第一个方案是用户态拷贝用mmap拿到V4L2缓冲区memcpy到DRM创建的dumb buffer里再提交给plane。简单直接几乎任何内核版本都支持调试方便但多一次内存拷贝。第二个方案是DMA-BUF导出用VIDIOC_EXPBUF把V4L2缓冲区导出为一个DMA-BUF文件描述符然后直接用这个FD创建DRM Framebuffer。这样同一个物理缓冲区被V4L2和DRM共享零拷贝但前提是内核支持videobuf2-dma-contig且你的摄像头驱动导出时带的是物理连续内存。我的建议是第一步先用用户态拷贝把整条链路跑通确认摄像头能出图、屏幕能显示、颜色格式对。之后再改成DMA-BUF做零拷贝优化。一上来就搞DMA-BUF出了问题你分不清是采集问题还是显示问题。3. V4L2采集端实操把USB摄像头的一帧帧抠出来3.1 V4L2核心ioctl调用链V4L2的编程模型是一个典型的“打开-配置-申请-入队-出队”循环。下面是我实际用的调用顺序每一步都有对应的ioctlint fd open(/dev/video0, O_RDWR); // 1. 查询能力 struct v4l2_capability cap; ioctl(fd, VIDIOC_QUERYCAP, cap); // 检查 cap.capabilities V4L2_CAP_VIDEO_CAPTURE // 检查 cap.capabilities V4L2_CAP_STREAMING // 2. 设置采集格式 struct v4l2_format fmt {0}; fmt.type V4L2_BUF_TYPE_VIDEO_CAPTURE; fmt.fmt.pix.width 1280; fmt.fmt.pix.height 720; fmt.fmt.pix.pixelformat V4L2_PIX_FMT_YUYV; fmt.fmt.pix.field V4L2_FIELD_NONE; ioctl(fd, VIDIOC_S_FMT, fmt); // 注意设置完后要读回fmt驱动可能不采用你给的值 // 3. 申请缓冲区 struct v4l2_requestbuffers req {0}; req.count 4; req.type V4L2_BUF_TYPE_VIDEO_CAPTURE; req.memory V4L2_MEMORY_MMAP; ioctl(fd, VIDIOC_REQBUFS, req); // 4. 映射缓冲区 for (int i 0; i req.count; i) { struct v4l2_buffer buf {0}; buf.type V4L2_BUF_TYPE_VIDEO_CAPTURE; buf.memory V4L2_MEMORY_MMAP; buf.index i; ioctl(fd, VIDIOC_QUERYBUF, buf); mmap(NULL, buf.length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, buf.m.offset); } // 5. 入队所有缓冲启动流 for (int i 0; i req.count; i) { ioctl(fd, VIDIOC_QBUF, buf); } ioctl(fd, VIDIOC_STREAMON, type); // 6. 循环取帧 while (1) { ioctl(fd, VIDIOC_DQBUF, buf); // 阻塞等待一帧 // 处理 buf.m.offset 指向的图像数据 ioctl(fd, VIDIOC_QBUF, buf); // 处理完放回队列 }这套调用顺序写下来基本上就是V4L2应用的标准范式。有一个细节容易被忽略VIDIOC_S_FMT之后一定要把结构体读回来检查。很多USB摄像头并不支持你指定的所有分辨率和格式驱动会选一个最接近的替代方案。你要是拿着预设值去计算缓冲区大小后面处理一定会出错。3.2 格式协商YUYV还是MJPG为什么我推荐YUYVUSB摄像头最常见的两种输出格式是YUYV一种非压缩YUV 4:2:2格式和MJPGMotion JPEG压缩流。YUYV直接能得到原始像素数据不需要解码但数据量很大。MJPG数据量小但每个帧是JPEG压缩包你得有解码器才能变成像素数组。RK3588平台上有MPPMedia Process Platform硬解码能力RealTek等方案也有类似模块。但注意咱们这篇的标题就是“无库依赖”MPP虽然不算传统意义上的用户态库但它已经是Rockchip平台相关的软硬件协同模块。如果项目允许依赖Rockchip的runtimeMJPGM硬解确实高效如果严格无第三方依赖就直接YUYV。实测中大部分1080p USB摄像头在USB 2.0带宽下YUYV只能跑到10~15fps而MJPG轻松30fps。这是因为USB 2.0实际有效带宽只有约320Mbps而1080p YUYV 30fps理论上要 192010802字节*30 ≈ 124MB/s ≈ 1Gbps远超USB 2.0能力。所以选YUYV时要么把分辨率降到720p或更低要么接受较低的帧率。我的做法是优先用720p YUYV在带宽和清晰度之间取平衡。3.3 USB摄像头在RK3588上的三个隐藏坑第一个坑是带宽协商不生效。有些摄像头驱动默认按照MJPG的带宽来配置URB缓冲数量。你切到YUYV之后如果缓冲区不够会看到DQBUF丢帧、帧率暴跌。可以用uvcvideo模块参数来调整URB数量# 查看当前URB配置 cat /sys/module/uvcvideo/parameters/urb_requests # 设置更多URB缓冲比如16 echo 16 /sys/module/uvcvideo/parameters/urb_requests第二个坑是设备节点不确定。如果你的板子上接了多个摄像头/dev/video0可能不是你要的那个。建议通过sysfs或者v4l2-ctl --list-devices来确认。写代码时不要硬编码video0做个扫描匹配的能力检查会稳妥很多。第三个坑是部分摄像头在VIDIOC_S_PARM设置帧率时不生效。你用ioctl设置了timeperframe为1/30摄像头根本不理会依然按自己的节奏出帧。遇到这种情况别纠结直接以DQBUF返回的实际帧间隔为准在应用层做时间戳统计。4. DRM/KMS显示端实操把内存里的帧交给VOP24.1 CRTC、Encoder、Connector、Plane四件套的角色DRM/KMS的概念对于新手来说一开始容易懵。我用一个放映厅的类比来解释Connector是投影墙的接口规格——你面对的是MIPI DSI屏幕还是HDMI电视Encoder是投影仪的信号处理器——把数字信号转成MIPI DSI协议CRTC是放映机本体——它按固定的时序把画面一帧一帧地扫出去Plane就像是放映机上的幻灯片槽每个槽可以放一张底片Framebuffer硬件可以把几个槽的内容叠在一起输出。RK3588的VOP2就是一套增强版的放映机。它提供多个plane底层plane可以放视频帧上层plane可以放UI叠加层硬件自动做混合。我们要做的是把摄像头帧放到其中一个plane上剩下的交给VOP2定时扫描输出到MIPI屏幕。4.2 从打开设备到画面点亮的关键代码路径以下是DRM显示侧的核心流程我尽量用libdrm已经封装好的函数来写这是最主流的无库依赖方式libdrm本身就是内核DRM的C封装体积小几乎所有嵌入式Linux都自带int drm_fd open(/dev/dri/card0, O_RDWR); // 1. 获取显示资源 drmModeRes *res drmModeGetResources(drm_fd); // 2. 找到已连接的Connector并取第一个Mode drmModeConnector *conn NULL; for (int i 0; i res-count_connectors; i) { conn drmModeGetConnector(drm_fd, res-connectors[i]); if (conn-connection DRM_MODE_CONNECTED) { break; } } drmModeModeInfo *mode conn-modes[0]; // 3. 从Connector找到Encoder再拿CRTC drmModeEncoder *enc drmModeGetEncoder(drm_fd, conn-encoder_id); int crtc_id enc-crtc_id; // 4. 创建并添加Framebuffer以YUYV为例需要确认plane是否支持 uint32_t handles[4] {dumb_handle}; uint32_t pitches[4] {width * 2}; // YUYV每像素2字节 uint32_t offsets[4] {0}; drmModeAddFB2(drm_fd, width, height, DRM_FORMAT_YUYV, handles, pitches, offsets, fb_id, 0); // 5. 获取一个plane drmModePlaneRes *pres drmModeGetPlaneResources(drm_fd); drmModePlane *plane drmModeGetPlane(drm_fd, pres-planes[0]); // 6. 把Framebuffer提交给plane drmModeSetPlane(drm_fd, plane-plane_id, crtc_id, fb_id, 0, 0, 0, mode-hdisplay, mode-vdisplay, 0, 0, mode-hdisplay 16, mode-vdisplay 16);注意第4步里的dumb buffer创建你还需要先用DRM_IOCTL_MODE_CREATE_DUMB创建一块显示内存再通过mmap映射到用户态去写像素数据struct drm_mode_create_dumb create {0}; create.width width; create.height height; create.bpp 16; // YUYV每个像素16bit drmIoctl(drm_fd, DRM_IOCTL_MODE_CREATE_DUMB, create); struct drm_mode_map_dumb map {0}; map.handle create.handle; drmIoctl(drm_fd, DRM_IOCTL_MODE_MAP_DUMB, map); uint8_t *vaddr mmap(NULL, create.size, PROT_READ | PROT_WRITE, MAP_SHARED, drm_fd, map.offset);之后你往vaddr写的像素数据最终会被VOP2扫到MIPI屏幕上。4.3 YUV帧直出的“免转换”玩法很多人习惯性地以为屏幕显示必须转成RGB。实际上DRM/KMS的plane是完全支持YUV格式直接输出的关键在于你选的那个plane是否支持你手里的格式。在Rockchip内核的VOP2驱动里底层plane通常支持NV12、YUV420、YUYV等格式。先用下面的代码查一下当前选中的plane支持哪些格式drmModePlane *plane drmModeGetPlane(drm_fd, pres-planes[i]); for (int j 0; j plane-count_formats; j) { printf(format: %c%c%c%c\n, (plane-formats[j] 0) 0xff, (plane-formats[j] 8) 0xff, (plane-formats[j] 16) 0xff, (plane-formats[j] 24) 0xff); }实测中RK3588的VOP2普遍提供对NV12/YUV420的支持有的内核版本对YUYV的支持取决于screen和plane的搭配。如果YUYV不直接被plane接受你只有两条路一是在应用层把YUYV转成NV12注意NV12是Y平面UV交错平面转换不是简单的yuyv字节序调整二是用Rockchip的RGA硬件做格式转换。RGA是RK芯片自带的2D加速器通过/dev/rga节点或者librga库访问严格说是Rockchip平台库而非通用第三方库按需取舍。4.4 竖屏改横屏别在应用层硬转先看plane能力MIPI屏幕的物理方向是固定的如果焊上去的是一块800x1280的竖屏VOP2按原生timing扫描输出就是竖的。要在竖屏上显示横向的摄像头画面你需要对图像做90度旋转。很多第一次做这个的人会在应用层暴力旋转——把每个像素重新映射。对于小分辨率比如480x640这没问题但到了1080p纯CPU旋转的开销很大。推荐顺序是先查plane的rotation能力部分内核的VOP2驱动支持DRM_MODE_ROTATE_90属性drmModeObjectProperties *props drmModeObjectGetProperties( drm_fd, plane-plane_id, DRM_MODE_OBJECT_PLANE); // 查找名为rotation的property检查其支持的bitmask // 如果支持DRM_MODE_ROTATE_90设置该属性即可硬件旋转 drmModeObjectSetProperty(drm_fd, plane-plane_id, prop_id, DRM_MODE_ROTATE_90);如果plane不带旋转能力那就只能靠RGA硬件旋转。RGA支持旋转、缩放、格式转换一体化处理效率远高于CPU。这里我想强调一个容易被忽略的细节无论你用什么方案旋转摄像头采集的分辨率和DRM mode的宽高是对不上的。竖屏mode是800x1280横屏画面是1280x720旋转之后你还得做缩放或者裁剪否则画面要么拉伸变形要么超出屏幕范围。5. 两条通路的衔接缓冲管理、帧率控制与性能取舍5.1 V4L2缓冲区与DRM Framebuffer的三种接法第一种接法用户态拷贝。V4L2 mmap得到的缓冲区和DRM dumb buffer都是用户态可写的直接memcpy。优点是很无脑缺点是同一帧数据在DDR里被搬运了一次。我在RK3588上实测1080p YUYV一帧约4MBmemcpy一次大概2~3ms看似不多但CPU占用会吃掉一个核心多路摄像头时这个开销会成倍增长。第二种接法DMA-BUF导出后零拷贝。操作路径是// V4L2侧导出 struct v4l2_exportbuffer exp {0}; exp.type V4L2_BUF_TYPE_VIDEO_CAPTURE; exp.index buf.index; exp.flags O_RDONLY; ioctl(v4l2_fd, VIDIOC_EXPBUF, exp); // 得到一个DMA-BUF fd然后传给drmModeAddFB2 drmModeAddFB2(drm_fd, width, height, DRM_FORMAT_YUYV, handles, pitches, offsets, fb_id, 0); // 此时handles[0]需要用drmPrimeFDToHandle把fd转成handle这种方式下V4L2的缓冲区直接被VOP2读取整条链路只有一次DMA写入USB控制器写内存和一次DMA读取VOP2读内存没有任何CPU参与。代价是缓冲区生命周期管理变复杂你必须等到VOP2扫描完这一帧之后才能把这块buffer重新入队给V4L2否则就会撕裂。通常做法是配合PageFlip完成回调来确认安全的回收时机。第三种接法用RGA做中转。摄像头帧先进RGA由RGA完成格式转换、旋转、缩放后写到显存再把显存里的buffer挂到plane上。这其实是工业项目里最常见的做法因为采集格式和显示格式往往不一致RGA正好充当万能转换器。5.2 帧率同步策略V4L2的DQBUF本身是阻塞的摄像头驱动来一帧你才能取一帧天然形成了采集帧率的上限。DRM显示侧有两种提交方式drmModeSetPlane是即刻提交简单直观但可能在VSYNC中间切换导致画面撕裂drmModePageFlip则会把切换操作同步到下一个垂直消隐期画面不会撕裂但你必须要处理DRM事件// 设置PageFlip并开启事件标志 drmModePageFlip(drm_fd, crtc_id, fb_id, DRM_MODE_PAGE_FLIP_EVENT, NULL); // 在循环里等待DRM事件 fd_set fds; FD_ZERO(fds); FD_SET(drm_fd, fds); select(drm_fd 1, fds, NULL, NULL, NULL); drmHandleEvent(drm_fd, event);如果显示帧率跟不上采集帧率你需要在应用层丢帧。常见的策略是始终显示最新帧跳过中间帧。也就是每次V4L2 DQBUF后不立即拷贝等到下一次VSYNC事件后才把最新的帧拷贝过去。这样屏幕不会为了等慢速的采集而卡住。5.3 性能实测1080p下CPU占用多少才算健康我用RK3588的Linux系统实测了几组数据基于用户态拷贝方案工况摄像头格式DRM Buffer格式CPU占用单核显示帧率720p YUYV memcpyYUYVYUYV约20%30fps1080p YUYV memcpyYUYVYUYV约45%12~15fps1080p YUYV RGA转NV12YUYVNV12约10%30fps1080p MJPG MPP解码 RGAMJPGNV12约15%30fps从数据可以看出来用户态memcpy在1080p下基本是瓶颈而RK3588的RGA和MPP硬件模块才是正解。如果你的项目最终要上1080p30建议直接跳过用户态拷贝一上来就设计成V4L2 → DMA-BUF或RGA → DRM的架构。6. 实战踩坑我在这块板子上翻过的六个车6.1 黑屏先分清是KMS配置问题还是VOP2管脚问题现象是程序运行正常、ioctl全部返回成功但屏幕就是黑的。我当时的排查顺序是先确认系统有没有识别到MIPI屏幕——在内核启动日志里搜索panel相关节点或者用modetest确认connector的状态。如果modetest都看不到MIPI连接器那就是设备树dts配置问题不是应用层问题。如果connector正常但显示黑多半是Framebuffer格式不匹配或plane没有正确绑定到CRTC。记得用drmModeSetPlane之后立即drmModePageFlip一次因为有些内核要求在SetPlane之后再触发一次CRTC重新扫描。6.2 花屏与撕裂缓冲生命周期没管好花屏最常见的原因是DQBUF取出一帧后你在它还没被显示完成时就修改了内容或者直接把它重新入队给了V4L2驱动驱动又在同一块内存上写入了新帧。两种操作都会导致VOP2扫描到一半发现数据变了。解决思路是至少要双缓冲一个缓冲正在被显示另一个缓冲正在被填充等PageFlip事件确认第一块显示完成后它才能被重新使用。撕裂则是因为提交发生在VSYNC中间用PageFlip替代SetPlane就解决了。6.3 帧率感人层层排查USB带宽与队列策略明明摄像头标称30fps实际显示却只有5fps。我在RK3588上遇到过一次排查询问链路出在USB带宽。摄像头插在USB 2.0口上输出YUYV 1080p带宽根本不够。排查方法很简单先在V4L2层统计DQBUF的帧数iamge没到用户态之前就丢帧那是采集带宽问题DQBUF出来的帧数正常但显示卡顿那是显示侧的buffer队列问题。把问题切割到单侧定位会容易很多。6.4 颜色全不对像素格式错配显示出来的图像颜色完全像色差信号错位蓝色变成橙色绿色变紫。这类问题基本是YUYV和NV12混用导致的。YUYV是打包格式一个像素一个亮度值加上两个色度值交错NV12是平面格式所有Y数据放一起UV数据放另一块。drmModeAddFB2里填写的DRM_FORMAT_必须和实际内存中的字节布局严格一致。我在调试时会先用一个纯色图像源做卡点测试确认颜色通道是正确的再接入摄像头帧。6.5 旋转后显示区域异常宽高信息要同步改搞定竖屏改横屏之后画面倒是横过来了但屏幕右侧和底部出现了黑边或者内容溢出。这个坑的根源是旋转后没有同步更新Framebuffer的宽高和plane的显示区域。旋转90度意味着源图像的width和height要互换如果你用RGA旋转输出buffer的宽高要预先设置成旋转后的尺寸plane的src和crtc坐标也要按mode的宽高重新设置。这一块没有统一公式必须在代码里用一个结构体把方向状态和宽高关系一起管理起来。6.6 PageFlip事件丢失不要在fd上死等我遇到过PageFlip提交之后事件永远等不到的情况。程序卡死在select上。原因是我忘了DRM事件需要循环调用drmHandleEvent或者当前线程没有权限读这个fd。更隐蔽的一个原因是如果你的KMS提交参数有误比如crtc_id不对内核会在dmesg里报错但应用层不会直接得到错误返回值此时DRM fd上永远不会有事件。遇到这种情况先看dmesg再看PageFlip的返回值最后检查fd是不是被意外设置了O_NONBLOCK。我在实际使用中最深的体会是V4L2和DRM这两个框架表面上是一堆ioctl的拼凑实际上它们的抽象层次做得非常好你把它们拆开理解再组合使用能够应对RK3588上绝大多数视频类需求。这套从摄像头到屏幕的链路一旦打通后续接yolov8做推理、转RTSP推流、多路画面拼接都只是在这条主干道上加插件。与其去背各种框架API不如先把这条底层通路走一遍它会成为你理解所有上层方案的地图。