1、多屏显示系统概述

各位同学，咱们今天聊聊多屏显示。说实话，我第一次接触多屏项目时，心里也没底。那是在一家做智能座舱的公司，客户要求中控、仪表、副驾娱乐三块屏同时跑，还要能联动。嗯，当时踩了不少坑，今天把这些经验分享给你。

多屏显示的应用场景

多屏显示不是炫技，是真实需求驱动的。我归纳了三个典型场景：

• 智能座舱：仪表盘、中控屏、抬头显示、后排娱乐。每块屏各司其职，但数据要互通。我在项目中遇到过，仪表盘显示导航信息时，中控屏要同步更新路线——这涉及跨屏通信，搞不好就卡顿。
• 工业控制：操作屏、监控屏、参数配置屏。操作屏坏了，监控屏得能接管。说白了，这是冗余设计，也是安全要求。
• 数字标牌：商场里的拼接屏、机场的航班信息屏。每块屏显示不同内容，但整体要协调。你想想看，如果一块屏时间不准，整个系统就露怯了。

多屏显示的技术架构

技术架构这块，我习惯从下往上分三层：

1. 硬件层

说白了就是显示控制器和接口。常见方案有：

• 单SoC多显示控制器：比如i.MX8M Plus，内置两个显示控制器，可以驱动两块屏。我建议小项目用这个，省成本。
• 多SoC级联：每个SoC带一块屏，通过以太网或PCIe通信。适合大系统，但同步是个坑。
• 外挂显示芯片：比如用DP或HDMI扩展芯片。嗯，这里要注意，外挂芯片的驱动往往要自己写。

2. 内核层

Linux内核里，多屏显示的核心是DRM/KMS框架。我简单说下：

• CRTC：显示控制器，负责生成时序信号。每个CRTC可以连一个encoder。
• Encoder：编码器，把CRTC的信号转成HDMI、DP等格式。
• Connector：物理接口，比如HDMI口、DP口。
• Plane：图层，每个CRTC可以有多个plane，实现叠加显示。

// 一个简单的多屏配置示例
struct drm_device *dev;
struct drm_crtc *crtc1, *crtc2;
struct drm_encoder *encoder1, *encoder2;
struct drm_connector *connector1, *connector2;

// 初始化两个CRTC
crtc1 = drm_crtc_init(dev, &crtc_funcs);
crtc2 = drm_crtc_init(dev, &crtc_funcs);

// 每个CRTC绑定一个encoder
encoder1->possible_crtcs = 1 << drm_crtc_index(crtc1);
encoder2->possible_crtcs = 1 << drm_crtc_index(crtc2);

3. 应用层

应用层主要做两件事：窗口管理和合成。常见方案：

• Wayland/Weston：支持多输出，每个输出可以独立配置分辨率。我建议新项目用这个。
• Qt for MCU：轻量级，适合资源受限的设备。
• 直接操作DRM：绕过窗口系统，直接写framebuffer。性能最好，但开发量大。

多屏显示的核心挑战

这部分是我最想说的。你想想看，多屏显示听起来简单，实际坑很多。我归纳了四个核心挑战：

挑战	描述	我的建议
帧同步	多屏内容更新不同步，出现撕裂	使用硬件vsync，或者用atomic commit
内存带宽	多屏同时刷新，带宽吃紧	用tiled格式，减少内存访问次数
分辨率差异	各屏分辨率不同，UI适配困难	用相对坐标，别写死像素值
热插拔	屏幕突然断开或接入，系统要稳定	注册hotplug回调，做好状态机

嗯，说到帧同步，我再多聊两句。多屏同步有两种方式：

• 软件同步：应用层统一提交帧，内核层同时切换。优点是简单，缺点是延迟大。
• 硬件同步：用硬件信号（比如GPIO）触发所有屏幕同时刷新。我建议对延迟敏感的场景用这个。

最后，我想强调一点：多屏显示不是简单的「多开几个fbdev」。它涉及显示控制器、内存管理、时钟同步等多个子系统。你如果只懂其中一个，很容易被坑。

好了，这一章就到这里。下一章咱们深入DRM/KMS框架，手把手教你写一个双屏驱动。有什么问题，咱们群里聊。