1. 项目概述双屏旋转调试的“硬骨头”在嵌入式显示系统开发里双屏异显并独立控制旋转方向绝对算得上是一块“硬骨头”。特别是基于Rockchip这类主流嵌入式平台当你需要在主屏显示一个横屏的仪表界面同时在副屏展示一个竖屏的菜单或信息流时问题就来了。系统默认的显示框架往往只认一个全局的旋转方向或者两个屏幕只能“同甘共苦”一起横或一起竖。这显然无法满足复杂的多任务交互场景。我最近就啃下了这块硬骨头完成了从底层驱动到上层应用的全链路调试。这个过程远不是改一个配置文件那么简单它涉及内核显示驱动、硬件合成器、窗口管理器和应用层的多级联动。网上关于libgl error: failed to load driver: rockchip的报错或者ion-heap内存分配的问题很多都只是这个复杂拼图中的一小块碎片。今天我就把这块“硬骨头”的啃法从思路到实操再到避坑完整地拆解一遍。无论你是正在调试RK3568、RK3588还是其他Rockchip平台这篇文章都能给你提供一个清晰的路线图。2. 核心思路与架构解析理解显示流水线在动手改代码之前必须把Rockchip平台上的显示流水线Display Pipeline搞清楚。盲目修改只会让你在无数个编译、烧录、重启的循环里迷失方向。2.1 Rockchip DRM/KMS 显示框架Rockchip的显示系统主要基于Linux内核的DRMDirect Rendering Manager和KMSKernel Mode Setting框架。你可以把它想象成一个高度流水线化的工厂应用层你的应用程序比如Qt程序、Android App是“客户”它下订单提交要显示的图像数据。窗口系统如Wayland/Weston, Android SurfaceFlinger这是“生产调度中心”它接收多个客户的订单决定哪个订单先生产以及把产品送到哪个流水线屏幕。Mali GPU / VPU这是“加工车间”负责对图像进行复杂的渲染、缩放、格式转换等处理。DRM/KMS驱动位于内核这是“流水线控制系统”和“传送带”。它管理着具体的物理显示设备如HDMI、LVDS、MIPI-DSI接口的屏幕控制它们的开关、分辨率、刷新率并把处理好的图像帧framebuffer按时送到对应的屏幕上去显示。硬件显示控制器VOP, Video Output Processor这是Rockchip芯片内部的“最终装配站”。一块Rockchip芯片通常有多个VOP如VOP0, VOP1每个VOP可以驱动一个或多个物理显示接口。双屏异显旋转的核心就在于如何让不同的VOP或者同一个VOP下的不同端口承载并处理经过不同旋转变换的图像流。在这个框架下“屏幕旋转”本质上是一个几何变换操作。这个操作可以在流水线的多个环节进行应用层旋转应用自己把画面画成旋转后的样子。简单但效率低且每个应用都要自己处理无法统一管理。窗口系统层旋转在调度中心就对所有窗口进行旋转合成。这是Android的常见做法通过SurfaceFlinger和HWComposer。DRM驱动层旋转在“传送带”上安装一个“旋转装置”这是最底层、最通用且高效的方式。Rockchip的DRM驱动通过rotation属性支持硬件或软件旋转。我们的目标是实现在驱动层或窗口系统层对两个屏幕的旋转状态进行独立、灵活的配置。2.2 双屏显示与旋转的关键数据结构在Linux DRM中有几个关键对象你需要熟悉drm_connector代表一个物理显示接口的连接状态如HDMI-1是否已插入。drm_crtc可以理解为一个“扫描引擎”负责定时从帧缓冲区读取数据并发送给显示器。一个VOP通常对应一个CRTC。drm_plane这是实现旋转、叠加等效果的核心。一个Plane代表一个图像层Layer。Rockchip的VOP通常支持多个Plane主平面、叠加平面等。旋转、缩放等变换属性正是设置在drm_plane上的。对于双屏常见的硬件连接方式有双VOP独立驱动例如RK3568的VOP0驱动HDMIVOP1驱动MIPI-DSI。这是最理想的情况两个屏幕完全独立可以分别设置旋转。单VOP多端口输出一个VOP通过不同的端口如RGB、LVDS、MIPI输出到两个屏幕。这种情况下两个屏幕共享同一个时序和分辨率基础实现独立旋转会复杂得多通常需要VOP支持“双通道”模式并为每个通道独立配置Plane。你的首要任务就是通过查看内核设备树dts和内核启动日志确认你的硬件属于哪种连接方式。注意在调试初期务必使用dmesg | grep -i vop或cat /sys/kernel/debug/dri/0/state如果debugfs已挂载来核实VOP和CRTC的分配情况。这是所有调试工作的基石。3. 设备树DTS配置硬件连接的蓝图设备树是告诉内核硬件如何连接的“蓝图”。双屏和旋转的配置从这里开始。3.1 基础双屏输出配置假设我们使用RK3568平台VOP0驱动HDMIVOP1驱动MIPI-DSI屏。一个简化的设备树配置示例如下// 在 dtsi 或 dts 文件中 vop0 { status okay; assigned-clocks cru DCLK_VOP0; assigned-clock-parents pmucru PLL_HPLL; // 指定此VOP支持的输出接口 ports { vop0_out: port0 { reg 0; #address-cells 1; #size-cells 0; vop0_out_hdmi: endpoint0 { reg 0; remote-endpoint hdmi_in_vop0; }; }; }; }; hdmi { status okay; // ... 其他HDMI配置 ports { hdmi_in: port0 { reg 0; hdmi_in_vop0: endpoint0 { remote-endpoint vop0_out_hdmi; }; }; }; }; vop1 { status okay; assigned-clocks cru DCLK_VOP1; assigned-clock-parents pmucru PLL_HPLL; ports { vop1_out: port0 { reg 0; #address-cells 1; #size-cells 0; vop1_out_dsi: endpoint0 { reg 0; remote-endpoint dsi_in_vop1; }; }; }; }; dsi { status okay; // ... DSI相关配置如通道数、视频模式 ports { dsi_in: port0 { reg 0; dsi_in_vop1: endpoint0 { remote-endpoint vop1_out_dsi; }; }; }; };这个配置建立了VOP0 - HDMI和VOP1 - DSI两条独立的显示通路。3.2 为屏幕指定初始旋转属性仅仅连通还不够我们需要为每个屏幕指定一个初始的旋转方向。这通常通过内核的DRM面板方向panel orientation属性来实现。这个属性会被驱动读取并应用到对应的drm_connector上。你需要在描述具体屏幕的节点中通常是dsi下的面板节点或hdmi连接器节点添加这个属性。但是更通用和推荐的做法是在用户空间通过udev规则或桌面环境如Weston、KDE的配置来设置。因为硬件安装方向比如副屏是物理竖屏是板级固定的而系统运行时可能还需要动态旋转。如果必须在设备树中指定可以尝试在面板节点中添加dsi_panel { compatible panel-dsi; // ... 其他面板参数 rotation 90; // 可选值0, 90, 180, 270 };请注意并非所有内核版本和驱动都支持直接从设备树读取rotation属性。更可靠的方式是驱动里写死或者通过后续的调试接口来设置。实操心得设备树配置是基础但改动后需要重新编译内核并烧录周期较长。在早期验证阶段我强烈建议先通过用户空间的工具如modetest来测试旋转功能是否可用确认硬件和驱动底层支持无误后再考虑固化到设备树或驱动中。4. 使用 modetest 进行底层验证modetest是libdrm工具集里的瑞士军刀它可以直接与内核DRM驱动交互绕过所有上层的窗口系统是验证驱动层双屏和旋转功能是否正常的黄金标准。4.1 确认显示设备与模式首先查看系统识别到的显示设备和它们支持的模式modetest -M rockchip输出会列出所有的connectors、encoders、crtcs和planes。找到你的两个屏幕对应的connectorID比如HDMI是connector 41DSI是connector 44并记下它们支持的显示模式mode例如1920x1080。4.2 测试单屏显示与旋转选择一个connector和一个crtc测试基本显示。同时我们可以测试plane的旋转属性。假设我们使用crtc 84和plane 88在connector 41HDMI上显示一个测试图案# 先清屏避免残留 modetest -M rockchip -s 4184:1920x1080 -P 8884:1920x1080 -w 88:rotation:0 # 然后设置一个固态颜色填充的FrameBuffer并显示 modetest -M rockchip -s 4184:1920x1080 -P 8884:1920x1080x0y0 -w 88:rotation:0 -a关键参数是-w plane_id:rotation:value。value可以是0: 不旋转 (DRM_MODE_ROTATE_0)1: 90度旋转 (DRM_MODE_ROTATE_90)2: 180度旋转 (DRM_MODE_ROTATE_180)3: 270度旋转 (DRM_MODE_ROTATE_270)重要旋转操作是作用在plane上的。你需要找到与你使用的crtc关联的plane。通常primary plane主平面的ID紧挨着对应的CRTC ID。4.3 测试双屏独立旋转这是最关键的一步。你需要为两个屏幕分别指定不同的crtc和plane并设置不同的rotation值。# 假设 # HDMI: connector_id41, crtc_id84, plane_id88 # DSI: connector_id44, crtc_id85, plane_id89 # 设置HDMI为横屏旋转0度DSI为竖屏旋转90度 # 步骤1设置两个屏幕的基本模式 modetest -M rockchip -s 4184:1920x1080 -s 4485:1080x1920 # 步骤2在两个plane上分别设置旋转并显示内容 # 注意旋转后图像的宽高逻辑会互换。对于DSI屏物理1080x1920旋转90度后应用层应提供1920x1080的图像。 modetest -M rockchip \ -P 8884:1920x1080x0y0 -w 88:rotation:0 \ -P 8985:1920x1080x0y0 -w 89:rotation:1 \ -a如果这个命令能成功执行并且两个屏幕一个横一个竖地显示了测试图案那么恭喜你驱动层支持双屏独立旋转的基础功能是完好的剩下的就是如何让窗口系统如Weston和应用使用这个功能。踩坑记录这里最容易出错的是plane的ID找错或者旋转后图像宽高不匹配导致显示异常或失败。务必仔细核对modetest的输出。另一个常见问题是ion-heap内存分配失败报错libgl error或DRM IOCTL失败这通常是因为系统预留的连续内存CMA不足。需要在内核配置中增大CMA大小例如在设备树中修改reserved-memory节点。5. 在 Weston 合成器中配置双屏旋转Weston是Wayland协议的一个参考合成器实现广泛用于嵌入式Linux GUI。我们需要配置Weston让它知道每个输出的物理方向并在合成时进行相应的旋转。5.1 Weston 输出配置 (weston.ini)Weston的配置文件通常是/etc/xdg/weston/weston.ini是控制多屏和旋转的核心。[core] # 启用多屏幕支持 shelldesktop-shell.so # 如果你的Weston版本较新可能需要指定后端 backenddrm-backend.so [output] # 配置第一个屏幕例如HDMI名称可以通过weston-info命令查看 nameHDMI-A-1 mode1920x108060 # 关键参数设置物理旋转可选 0, 90, 180, 270 transform0 [output] # 配置第二个屏幕例如DSI nameDSI-1 # 注意如果屏幕物理是竖屏这里的分辨率要写物理分辨率如1080x1920 mode1080x192060 # 将此屏幕旋转90度 transform90 # 有些版本可能需要指定scale对于旋转屏幕scale1即可 scale1 # 如果需要可以指定屏幕位置如放在主屏右边 position1920,0transform参数直接对应DRM的旋转属性。Weston在合成时会先根据这个参数对整个屏幕的帧缓冲区进行旋转然后再输出到对应的connector。5.2 验证与调试 Weston 配置获取输出名称启动一个基础的Weston后在终端里运行weston-info在输出的output部分找到每个屏幕的name如HDMI-A-1和对应的physical_width、physical_height。确认其是否与物理屏幕匹配。热重载配置修改weston.ini后不需要重启整个Weston。在Weston的终端里按CtrlAltBackspace调出调试面板选择“Reload Configuration”即可生效。这是一个非常高效的调试方式。查看日志启动Weston时添加--log/tmp/weston.log参数或者通过journalctl -f查看系统日志关注DRM相关的错误信息特别是设置transform时是否有报错。注意事项transform旋转的是整个输出Output这意味着在这个输出上运行的所有应用窗口都会被整体旋转。如果某个应用比如一个视频播放器自己内部又做了一次旋转可能会出现画面颠倒的情况。这时需要禁用应用自身的旋转逻辑。6. 应用层适配让应用“知道”屏幕方向对于运行在WaylandWeston之上的应用它们需要感知屏幕的旋转以调整自己的UI布局。这主要通过两种方式6.1 通过 Wayland 协议监听输出变更应用可以监听wl_output接口的geometry和mode事件。当Weston因为transform改变而通知应用时应用的窗口会收到configure事件其中包含新的窗口尺寸旋转后逻辑尺寸可能互换。一个良好的GUI框架如Qt Wayland、GTK会自动处理这些事件并触发相应的重绘或布局调整。对于Qt应用确保在main.cpp中正确设置了平台插件并处理了高DPI和缩放QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);Qt的Wayland平台插件会自动从合成器获取输出信息。6.2 应用内手动旋转渲染内容在某些情况下你可能需要手动控制渲染内容的旋转。例如一个全屏的OpenGL ES应用。这时你需要在渲染管线中插入一个旋转矩阵。// 伪代码示例在渲染循环中 void render_frame() { int screen_rotation get_screen_rotation_from_wayland(); // 从Wayland接口获取 glm::mat4 rotation_matrix glm::mat4(1.0f); switch(screen_rotation) { case 90: rotation_matrix glm::rotate(rotation_matrix, glm::radians(90.0f), glm::vec3(0.0f, 0.0f, 1.0f)); // 注意旋转后视口viewport也需要调整 glViewport(0, 0, physical_height, physical_width); break; // ... 其他角度 default: glViewport(0, 0, physical_width, physical_height); break; } // 将旋转矩阵传入着色器 glUniformMatrix4fv(rotation_loc, 1, GL_FALSE, glm::value_ptr(rotation_matrix)); // ... 后续渲染 }核心原则优先依赖窗口系统Weston的transform进行全局旋转让应用自动适配。只有在进行底层图形渲染游戏、视频播放或遇到特定兼容性问题时才考虑应用内手动旋转。7. 常见问题排查与实战技巧调试过程中我遇到了无数坑。这里把最常见的问题和解决方法整理成表希望能帮你节省大量时间。问题现象可能原因排查方法与解决方案modetest设置旋转失败IOCTL错误1. 使用的plane不支持旋转。2. DRM驱动中该plane的rotation属性未正确暴露或初始化。3. 旋转后要求的帧缓冲区格式驱动不支持。1. 用modetest -M rockchip -p查看plane的属性列表确认是否有rotation属性。2. 检查内核驱动源码如rockchip_drm_vop.c看plane的rotation属性是否在atomic_check和atomic_update函数中正确处理。3. 尝试更换帧缓冲区格式如从XR24换成AR24。一个屏幕旋转成功另一个花屏或黑屏1. 两个屏幕共享同一个VOP但该VOP的硬件双通道配置有误。2. 为两个屏幕分配的帧缓冲区内存CMA不足或地址冲突。3. 屏幕时序dts中的display-timings在旋转后不匹配。1. 检查内核日志dmesg搜索vop、iommu、ion错误。2. 增大设备树中reserved-memory节点的CMA区域大小。3. 用示波器或逻辑分析仪抓取旋转后屏幕的时序信号与屏规对比。或尝试微调dts中的hsync-len,vsync-len等参数。Weston启动后旋转的屏幕内容错位或只有一部分1. Weston的transform设置后但mode分辨率仍为物理分辨率导致逻辑错误。2. 屏幕的physical_width/height信息EDID或驱动上报错误。1. 在weston.ini中对于旋转90/270度的屏幕尝试将mode也设置为旋转后的逻辑分辨率如物理1080x1920竖屏旋转90度后mode可尝试设为1920x1080。2. 强制在weston.ini中用physical_width和physical_height指定正确值。应用如Qt程序在旋转屏幕上窗口大小不对应用未正确处理Wayland的configure事件或者应用的窗口管理器兼容性问题。1. 更新Qt到较新版本其对Wayland多屏旋转支持更好。2. 设置环境变量QT_WAYLAND_FORCE_DPIphysical或QT_SCALE_FACTOR_ROUNDING_POLICYRoundPreferFloor进行调试。3. 在应用启动命令前加GDK_DEBUGupdatesGTK应用查看布局事件。系统出现libgl error: failed to load driver: rockchip1. Mali GPU驱动未正确安装或初始化。2.ion内存分配器故障导致GPU无法获取渲染缓冲区。此问题常与旋转并发因旋转需要额外内存1. 检查/usr/lib/libmali.so是否存在并确认是正确版本如midgard-t76x-r18p0。2. 检查dmesg中关于ion或mali的错误。最根本的解决方法是增大CMA内存。在设备树中reserved-memory { linux,cma { size 0x40000000; // 1GB }; };动态旋转如通过传感器时系统卡顿或闪屏1. 旋转操作触发全屏重合成性能开销大。2. 应用层、合成器层、驱动层旋转逻辑冲突导致反复调整。1. 确保使用DRM的atomic commit进行旋转设置它比legacy setcrtc更高效。2. 统一旋转控制权。最佳实践是传感器-应用服务-通过DBus等IPC通知Weston或直接写DRM属性-Weston设置transform避免多层控制。独家避坑技巧调试利器drmsink与gstreamer当画面显示异常时可以用GStreamer管道直接将测试视频输出到具体DRM设备绕过所有上层合成快速定位问题层。gst-launch-1.0 videotestsrc ! drmsink device/dev/dri/card0 connector-id41 crtc-id84 plane-id88内核调试信息编译内核时开启CONFIG_DRM_DEBUG_MODESET、CONFIG_DRM_ROCKCHIP_DEBUG等选项让内核打印更详细的DRM状态变更信息。先单后双先静后动务必先确保单个屏幕的各个旋转角度都能正常工作再接入第二个屏幕。先测试静态配置weston.ini再实现动态旋转逻辑。8. 进阶动态旋转与传感器联动实现“自动旋转”是双屏旋转调试的进阶目标。这需要建立一个从传感器到显示的完整事件链。传感器数据读取通过iio接口或传感器专用驱动如ak8975读取加速度计、陀螺仪数据计算设备朝向。方向决策服务编写一个后台服务如C/Python程序过滤传感器数据判断当前应有的屏幕方向0, 90, 180, 270。并加入去抖和 hysteresis迟滞逻辑防止在临界角度频繁旋转。控制合成器旋转Wayland (Weston)Weston提供了weston-drm后端的一个私有接口可以通过DBus或者直接向Weston的wl_drm对象发送请求来动态改变transform。更实际的方法是你的服务通过DBus调用一个自定义的Weston插件或者直接向Weston进程发送信号如SIGUSR1在插件或信号处理函数中调用weston_output_set_transform()API。直接控制DRM你的服务可以直接打开/dev/dri/cardX设备使用libdrm库像modetest一样通过drmModeAtomicCommit提交一个包含rotation属性变更的原子操作。注意这需要与正在运行的合成器Weston协调好否则会出现资源竞争导致画面撕裂或崩溃。通常合成器是DRM的主设备Master非主设备无法进行模式设置。通知应用当屏幕方向改变后Wayland合成器会通过wl_output事件通知所有应用合规的应用会自动调整。架构建议对于产品化系统推荐采用“传感器服务 - DBus - Weston插件 - DRM原子提交”的路径。将旋转控制权集中到合成器是最稳定、兼容性最好的方案。整个调试过程就像在解一个多层的谜题。从底层的设备树、驱动属性到中间层的合成器配置再到上层的应用适配每一层都要打通。最深刻的体会是一定要善用modetest这类底层工具进行“单元测试”它能帮你把问题范围快速锁定在驱动层还是应用层。当两个屏幕按照你的指令一个横一个竖稳定点亮时那种成就感就是对所有调试工作最好的回报。最后一个小建议把所有成功的配置命令和参数以及对应的硬件状态详细记录在一个文档里下次再遇到类似平台你会感谢现在这个细心记录的自己。