第一章 车载图形系统概述
1.1 车载显示系统的发展历程
说起车载显示，我入行那会儿还是机械仪表盘的天下。一个转速表、一个速度表，再加几个指示灯，就齐活了。那时候的「显示」，说白了就是指针转一转。
后来液晶屏开始进入汽车。我记得2010年左右，第一批7寸中控屏出现在高端车型上。分辨率只有800x480，但已经让整个行业兴奋不已。为什么？因为终于可以显示地图了。
再往后，发展速度就快得吓人了：
- 2013-2015年：12.3寸全液晶仪表开始普及，分辨率提升到1280x480
- 2016-2018年：双屏设计出现，中控+仪表各一块屏
- 2019-2021年：三联屏、贯穿屏成为主流，分辨率达到2K甚至4K
- 2022年至今：AR-HUD、电子后视镜、后排娱乐屏，整车屏幕数量突破10块
你想想看，十年前一辆车只有1块屏，现在动辄6-8块。这背后对图形系统的要求，完全不是一个量级。
核心变化：从「能显示」到「显示得好」，从「单屏独立」到「多屏联动」，从「静态界面」到「实时3D渲染」。
1.2 现代车载HMI架构
现在的车载HMI架构，我习惯把它分成三层来看：
硬件层
主控SoC + 独立GPU + 显示控制器。嗯，这里有个坑——很多方案用一颗SoC驱动多块屏幕，但显示控制器的通道数有限。我在项目中就遇到过，明明SoC支持3路显示，但实际只能同时输出2路，因为第三路和摄像头ISP复用了。
图形栈层
这一层是重点。从底层往上走：
- DRM/KMS：直接操作显示控制器，负责帧缓冲和模式设置
- GPU驱动：通常是DRM的GEM子系统和调度器
- 合成器：Wayland compositor或SurfaceFlinger
- UI框架：Qt、Flutter、Kanzi等
应用层
仪表、中控、空调、导航、语音助手……每个应用跑在自己的Surface上，由合成器统一管理。
我的建议：设计架构时，一定要把「安全隔离」放在第一位。仪表和中控不能互相影响，这是底线。
1.3 Wayland在车载领域的优势
为什么车载行业现在都在转向Wayland？说白了，X11那套东西已经撑不住了。
我简单列几个关键点：
| 对比项 | X11 | Wayland |
|---|---|---|
| 架构 | Client-Server，X Server是中心 | Client-Compositor，去中心化 |
| 渲染路径 | Client→Server→Kernel→显示 | Client→Compositor→Kernel→显示 |
| 延迟 | 2-3帧的额外延迟 | 1帧以内，支持直接提交 |
| 安全性 | 所有Client都能看到其他Client的窗口 | 隔离性好，Client只能看到自己的Surface |
| 多屏支持 | 需要Xinerama或XRandR，复杂 | 原生支持，每个输出独立管理 |
你看这个表格就明白了。Wayland在延迟和安全性上，天生就比X11强。
具体到车载场景，我总结三个核心优势：
1. 低延迟，高帧率
Wayland的合成器直接和DRM/KMS交互，不走中间环节。我在实际项目中测过，同样的Qt应用，Wayland下触摸到显示的延迟比X11低了30%左右。这对仪表盘来说太重要了——你总不希望车速显示滞后吧？
2. 安全隔离
每个应用跑在自己的Surface上，合成器决定谁能看到谁。仪表应用看不到中控的内容，中控应用也改不了仪表的显示。这在X11下几乎不可能做到。
注意：安全隔离不是「有就行」，而是要经过实际攻击测试。我曾经见过一个方案，虽然用了Wayland，但compositor的权限控制没做好，结果一个第三方应用还是能通过截屏获取到仪表信息。
3. 多屏原生支持
Wayland的协议设计就考虑了多输出场景。每个输出（屏幕）可以有自己的分辨率、刷新率、旋转角度。compositor可以灵活地把Surface分配到不同屏幕上。
举个例子，我做过一个三屏方案：
输出0: 仪表盘 (1920x720 @ 60Hz)
输出1: 中控屏 (1920x1080 @ 60Hz)
输出2: 副驾屏 (1920x1080 @ 60Hz)
每个输出独立渲染，互不干扰。
仪表盘应用只绑定到输出0。
中控和副驾应用可以跨屏拖拽。这在X11下配置起来相当麻烦，但在Wayland下，compositor启动时指定几个输出就行了。
1.4 实际项目中的经验
说了这么多理论，我分享一个真实案例。
去年我参与一个项目，客户要求用一颗高通SA8155P芯片驱动4块屏幕：仪表、中控、副驾、后排。一开始他们想用X11，理由是「成熟稳定」。
结果呢？
- X11下4块屏幕的配置花了3周，各种CRTC和Encoder的映射问题
- 仪表和中控之间偶尔出现画面撕裂
- 后排屏幕播放视频时，中控操作会卡顿
后来我们改成Wayland + Weston，只用了1周就完成了多屏配置。画面撕裂问题通过设置每个输出的独立刷新率解决了。至于卡顿——Wayland的buffer管理机制天然避免了这种问题。
结论：不是X11不能用，而是Wayland更适合车载这种对实时性、安全性、多屏支持要求高的场景。
1.5 本章小结
车载显示从机械到数字，从单屏到多屏，从简单到复杂。Wayland的出现，正好解决了这个阶段最头疼的几个问题。
下一章，我会带大家动手搭建一个Wayland开发环境。到时候咱们直接上代码，看看一个最简单的compositor是怎么跑起来的。
嗯，先消化这些吧。有问题随时问我。
公众号:蓝海资料掘金营，微信deep3321