最近在 STM32MP257F-DK 上折腾一块 1.54 寸 ST7789v 屏幕一开始我以为接上 SPI、点亮背光、发送初始化序列就能跑结果在 Linux 这边绕了不少弯路。这块板子的原生显示接口是 RGB/LVDS/DSI按说接一块 240x320 的 SPI 小屏有点“杀鸡用牛刀”但实际做下来发现这个场景非常典型很多原型项目、调试面板、小型人机界面都需要在嵌入式 Linux 平台上挂一块低成本 SPI LCD。而要用好这块屏关键不是“怎么发命令”而是“怎么把它接入 KMS DRM 框架”。这篇文章就围绕“STM32MP257F-DK ST7789v KMS DRM”整条链路展开从为什么选 DRM 而不是其他方案、内核配置和设备树怎么写、用户态怎么验证到图片显示、取模习惯的转变、常见问题排查全部梳理一遍。适合想在 MP2、i.MX 这类 Linux 平台上挂 SPI 小屏的工程师参考也适合刚接触 DRM 显示架构、想知道一块小屏是怎么变成系统标准显示设备的同学。1. 项目背景与方案选型为什么在 MP257F-DK 上挂 ST7789V1.1 这个项目到底在做什么STM32MP257F-DK 是 ST 新一代 MP2 系列评估板主芯片是双核 Cortex-A35 加 Cortex-M33 的异构处理器还带 2D/3D GPU 和丰富的显示接口。按官方定位这块板子一般会接 RGB 并口屏、LVDS 屏或者 MIPI DSI 屏配套的软件也是围绕这些大屏来的。但我这次的需求比较特殊项目里只需要一个 2.4 寸以内的副屏用来显示设备状态、运行日志、几个实时参数不需要高分辨率也不需要跑复杂动画。在这个前提下ST7789v 模块就很有优势驱动 IC 非常成熟、价格低、资料多SPI 接口只占几根线PCB 走线也方便。虽然 MP257F-DK 本身没有预留 ST7789v 的专用接口但 SPI 引脚和 GPIO 都能从扩展排针拉出来硬件上完全可行。真正需要解决的是软件层面的问题Linux 系统里不认这块屏我们得让它在内核里乖乖成为一个 DRM 设备。还要说明一下ST7789v 并不只有 SPI 一种接法它本身也支持 MPU 并口DBI Type B/C当初很多 MCU 方案就是走并口刷屏的。不过在 MP257F-DK 这类 Linux 平台上并口的接线太多、驱动适配也不方便几乎没有人在 Linux 下这样干。主流做法还是 SPI 接法这也是内核 DRM 驱动里支持得最好的方式。1.2 为什么选 KMS DRM而不是老办法如果你以前在嵌入式 Linux 上点过 SPI 屏可能听说过 fbtft或者干脆用 spidev 在用户态直接拉 GPIO、发命令、刷帧缓冲。这两种方式不能说不能用但在 STM32MP257F-DK 这种带 GPU、带 Weston、可能要跑 Qt 或 LVGL 的平台上会有明显痛点。fbtft 其实是一个 FBFrameBuffer驱动框架曾经很流行但内核社区这些年已经把它慢慢转向 DRM。很多老的 fbtft 驱动长期没人维护设备树绑定和现代内核的 display pipeline 越来越不搭。如果你只是用一个简单的框架可能还能跑但一旦想跟 GPU 合成、多图层、光标叠加甚至 GBM/Wayland 协作FB 架构会非常难受。用户态用 spidev 直接刷屏就更不省心你需要自己写完整的初始化序列、维护帧缓冲、处理背光、处理刷新时机而且应用层一旦多个进程同时显示画面管理完全失控。这在生产项目里基本不可维护。KMS/DRM 是 Linux 内核现在的标准显示架构。它的核心思路是内核负责显示硬件的所有细节包括初始化、Mode Setting、显存管理和扫描输出用户态只要通过/dev/dri/card0打开设备用 DRM API 去分配 framebuffer、设置显示模式、提交画面。对应用开发者来说屏幕只是一个标准输出设备至于它后面是 MIPI DSI 大屏还是 SPI 小屏根本不关心。还有一个现实原因内核里已经有现成的 ST7789v DRM 驱动路径在drivers/gpu/drm/tiny/st7789v.c基于DRM_MIPI_DBI辅助框架实现。DRM_MIPI_DBI 就是专门给 SPI/并口这类 CPU 接口屏准备的通用层它把 MIPI DBI 命令封装好通过 SPI 发到屏幕 IC。ST 这套 BSP 内核基本都带着它我们只需要把设备树配置好驱动加载后屏幕就能被系统自动识别。1.3 硬件连接和组件清单我的硬件连接很简单把 ST7789v 模块接到 MP257F-DK 扩展排针上。模块型号是常见的 1.54 寸、分辨率 240x320、白色 PCB 版本驱动 IC 是 ST7789v。接线关系可以参考下面这个表实际引脚号要对照你自己的原理图。ST7789v 模块引脚接到 MP257F-DK 的位置说明VCC / VDD3.3V 电源模块一般 3.3V 供电注意不要接到 5VGNDGND共地SCL / SCKSPI1_SCKSPI 时钟SDA / MOSISPI1_MOSISPI 数据CSSPI1_CS 或任意 GPIO片选我用的是 GPIO 控制DC / AOGPIO数据/命令选择必须接 GPIORESET / RSTGPIO复位信号必须接 GPIOBLK / BacklightGPIO 或 PWM背光控制可接 GPIO 高电平点亮连接顺序上我建议先把 VCC、GND、背光这三根线接好确认屏幕能上电再接 SPI 的 SCK/MOSI 和 CS最后接 DC 和 RESET。不要一上来就把所有线接完否则后面出问题定位困难。有一点要特别注意ST7789v 模块的工作电压是 3.3V但很多模块板载了稳压和电平转换电路板子上的 VCC 甚至可以接 5V。不过在 MP257F-DK 上还是统一用 3.3V 最稳妥避免和 GPIO 电平不一致。2. 内核驱动与配置把 ST7789v 变成 DRM 设备2.1 内核配置项与依赖关系项目内核版本是 ST 官方 SDK 提供的基于主线内核 6.x 的 BSP 分支drivers/gpu/drm/tiny/st7789v.c这个文件是存在的。如果你用的内核版本太老或者裁剪太狠可能没有这个驱动这时要回主线内核把drivers/gpu/drm/tiny/目录下相关文件移植过来或者确认 BSP 有没有把该驱动单独做成 patch。在 menuconfig 里搜索ST7789V可以看到配置项是CONFIG_DRM_ST7789V它的依赖关系大概是CONFIG_DRM必须开启CONFIG_DRM_MIPI_DBI必须开启这是 SPI 屏接入 DRM 的基础CONFIG_DRM_KMS_HELPER一般会自动打开CONFIG_SPI和对应的 SPI 控制器驱动必须开启比如CONFIG_SPI_STM32如果希望用户态像以前一样能通过/dev/fb0来访问屏幕还要打开 DRM 的 fbdev 模拟层不同内核版本名字不太一样一般是CONFIG_DRM_FBDEV_EMULATION。这层模拟会把 DRM framebuffer 暴露成传统 Linux fb 设备很多老工具、脚本可以直接用排查问题特别方便。我实际操作时先用stm32mp257f-dk_defconfig生成基础配置然后make menuconfig做增量修改。配置完成后记得把关键的配置项记下来make ARCHarm stm32mp257f-dk_defconfig make ARCHarm menuconfig # 在 Device Drivers - Graphics support - DRM driver for ST7789V 处打开 make ARCHarm uImage dtbs LOADADDR0xC2000000编译命令里的LOADADDR要根据你的启动方式确认如果是 SD 卡启动、用 ST 的 bootfs 目录直接更新内核镜像和设备树文件就行。如果是在 U-Boot 里用 tftp 或者 fastboot 刷写流程略有不同但核心不变把新的kernel和dtb放到启动环境能加载到的地方。2.2 设备树节点编写SPI 控制器与 panel 子节点设备树是这次能点亮屏幕最关键的一步。ST7789v 在 DRM 驱动模型里是一个“panel”它挂在一个 SPI 控制器的子节点下同时通过 GPIO 控制 DC 和 RESET。先看一段我实际用的设备树配置骨架注意 GPIO 编号只是示意必须改成你自己板子上的实际引脚。/ { backlight: backlight { compatible gpio-backlight; gpios gpioc 4 GPIO_ACTIVE_HIGH; default-on; }; }; spi1 { status okay; cs-gpios gpiod 3 GPIO_ACTIVE_LOW; pinctrl-0 spi1_pins_b; pinctrl-names default; st7789v_panel: st7789v0 { compatible st7789v; reg 0; spi-max-frequency 20000000; dc-gpios gpiod 11 GPIO_ACTIVE_LOW; reset-gpios gpioc 5 GPIO_ACTIVE_LOW; backlight backlight; rotation 0; status okay; }; };这里几个属性的作用要和你说清楚compatible st7789v是让内核驱动匹配设备树节点的关键。不同内核版本的 st7789v 驱动of_match_table可能有差异有的写成sinovoip,bpi-m2z有的直接写st7789v。遇到驱动不 probe 的情况第一件事就是打开drivers/gpu/drm/tiny/st7789v.c看一眼它到底匹配什么字符串以源码为准。dc-gpios是命令/数据选择线ST7789v 通过这一根线区分传输的是命令还是像素数据。DRM 的 MIPI DBI 框架在发命令时会把它拉低发数据时拉高。这根线接错或者没有配置屏幕会处于莫名其妙的“半命令半数据”状态显示效果就是纯花屏。reset-gpios是复位线低有效。驱动 probe 时会先把复位拉低、等一段时间再拉高屏幕 IC 才能正常初始化。有些屏幕模块上拉了一个 RC 复位电路不接也能复位但为了保证初始化时序可靠强烈建议接到 GPIO 上。rotation是屏幕旋转方向。ST7789v 模块出厂时引脚、接线不同同样的数据可能在屏上显示是倒的或镜像的。DRM 驱动会通过rotation属性让面板控制器设置 MADCTL 寄存器0、90、180、270可以分别试。注意这里的旋转是硬件层面和 GPU 合成的旋转不是一回事。spi-max-frequency代表 SPI 时钟最高频率。ST7789v 支持到几十 MHz但连接到 MP257F-DK 的杜邦线越长、走线越差实际能稳定跑的频率就越低。我调试时先用 10MHz 保证点亮稳定后再逐步提高。20MHz 在短排线上一般没问题再高就要检查信号质量。2.3 编译、烧录与驱动加载验证设备树改完后重新编译 dtb然后拷贝到启动分区。如果你用的是 SD 卡启动一般会有一个小的 FAT/bootfs 分区里面放着*.dtb和内核镜像。替换时最好先备份原文件因为很多时候你只是改了设备树但忘了其他模块的兼容性。上电启动后先看内核日志里有没有 ST7789v 相关打印dmesg | grep -i st7789如果驱动正常 probe你会看到类似st7789v spi1.0: supply io-vcc not found之类的提示有些是警告可忽略随后日志里会出现drm初始化相关输出。再看/dev/dri/下有没有设备节点ls -l /dev/dri/正常情况下会有card0表示 DRM 主设备已经创建。如果只有card0而没有card1说明面板已经作为 connector 挂到 card0 上。再用dmesg | grep drm看一下这个 DRM 设备挂了哪些 connector能不能读到240x320这个分辨率。这里我踩过的坑是设备树里 SPI 控制器没有正确引用cs-gpios导致 SPI 子节点从未被枚举/dev/dri/card0一直出不来。排查方法也很简单先看dmesg | grep spi如果 SPI 控制器都不工作面板驱动自然无从挂载。3. 用户态验证从 modetest 到 Weston3.1 用 modetest 确认设备枚举和显示模式驱动加载只是第一步真正可不可靠要看用户态能不能正常做 Mode Setting。modetest是libdrm自带的调试工具在没有桌面环境的嵌入式 Linux 上是最直接的验证工具。先列出所有 DRM 资源modetest -M stm -c这里的-M stm是告诉 modetest 使用哪个 DRM driver name。如果你的内核 driver 不叫stm可以先跑modetest -M help或者直接看/sys/class/drm/card0/device/driver_override。-c参数列出 connectors、modes、encoders。正常情况会看到有一个 connector 的modes列表里有240x320并且说明这个 connector 是PANEL类型。如果模模式列表里没有 240x320说明 panel 驱动没有正确上报 EDID 或 mode多半是分辨率参数和驱动不匹配。接着试一下直接提交模式看屏幕能否点亮modetest -M stm -s 42:240x320这条命令里的42是 connector ID要从上一步的输出里查。执行后屏幕应该会显示一个由 DRM 生成的测试画面通常是彩色条纹或纯色块。如果这一步能看到画面说明 GPU/CRTC/encoder/connector/panel 整条链路已经通了后续所有应用显示都只是常规操作。如果modetest -s报错比如Invalid mode或者Failed to set mode要重点看内核日志里有没有drm_connector相关的错误。很多时候是rotation配置和实际屏幕硬件方向不匹配导致设置的坐标范围超出屏幕物理尺寸内核直接拒绝提交。3.2 用 modetest 直接刷一张测试图modetest除了可以设置模式还能往 plane 提交一个带颜色的填充画面。用这条命令可以方便地验证显示方向、颜色格式是否正常modetest -M stm -s 42:240x320 -d 73 -f 25-d 73是 plane ID-f后面的数字是测试图案类型默认会有 r/g/b 彩虹条、纯色、渐变等。建议大家把-f 0到-f 9都试一遍画面能跟着变化说明 framebuffer、扫描输出、SPI 数据传输都正常。这一步比直接接 Weston 更容易判断故障点。如果你用过老式 fbdev 工具这里有一个天然优势DRM 的 fbdev 模拟层打开后屏幕会同时出现在/dev/fb0。用fbset查看fbset -fb /dev/fb0如果能看到geometry 240 320 240 320 16这样的输出说明 fbdev 节点也正常。你甚至可以直接用传统工具往/dev/fb0里写数据效果和写老式 LCD 驱动完全一样。对于做惯了 MCU 开发、熟悉/dev/fb0的工程师来说这个节点特别有亲切感。3.3 跑 Weston 验证合成器modetest 能亮只能证明显示通路没问题。如果你后续要跑 Wayland 应用或者 GUI 框架最好直接用 Weston 做一次真实负载测试。在 ST SDK 里Weston 一般已经在 rootfs 里预装好了只需要确认 weston.ini 的配置。最小可运行配置大概是这样的[core] shelldesktop-shell.so backenddrm-backend.so [output] namestm mode240x320 transformnormal关键是[output]里要指定name这个名字要和你 DRM driver 的名字一致。启动时也可以用命令行强制指定weston --backenddrm-backend.so --connector42Weston 起来后屏幕会变成桌面背景再跑一个glmark2-es2或者简单的 Wayland 客户端看有没有渲染内容。这里要有个心理预期240x320 的 SPI 屏刷新率很低Weston 桌面动画看起来会“卡顿”这是硬件带宽限制不是驱动有问题。在调试阶段我更推荐先跑静态应用比如weston-simple-egl显示一张静态纹理确认合成和 scanout 都正常然后再考虑跑动画类应用。4. 图片显示与“取模”习惯的转变4.1 从“取模”到“直接渲染”思维要变热词里有“st7789v 图片取模”这个词我在 MCU 圈子里太熟悉了。以前用 STM32F1/F4 裸机驱动 ST7789v 时要在屏幕上显示一张图片就得先把图片交给 PC 端工具处理成 C 语言数组输出 RGB565 或者 RGB666 格式的十六进制数据再把数组memcpy到 LCD 显存整个流程非常痛苦。图片稍微大一点Flash 就爆炸。但到了 Linux DRM 这个环境“取模”这件事基本可以丢掉了。原因是系统里有了真正的内存管理和文件系统图片以 PNG、JPEG、BMP 等格式存在由用户态程序负责解码再把解码后的 RGB 像素数据提交给 DRM。你不需要在编译期把图片硬编码成数组也不需要担心 RAM 不够——分配 framebuffer、管理显存都是内核和 libdrm 的职责。当然如果你想快速在屏幕上看到一张固定图片用来验证颜色、翻转方向、清晰度还是有一条非常像“取模”的路径把图片转成 240x320 的 RGB565 raw 数据然后直接写到/dev/fb0。4.2 用 ffmpeg 生成 RGB565 图片并写入 fb我调试时最常用的命令是ffmpeg -i test.png -f rawvideo -pix_fmt rgb565le -s 240x320 test.raw dd iftest.raw of/dev/fb0 bs1024这条命令的意思是把test.png强制缩放成 240x320只保留 RGB565 数据不打包、不压缩输出到test.raw然后直接用dd写到/dev/fb0的 framebuffer 中。屏幕上立刻就会显示出这张图。注意这里有个细节dd的bs可以随意关键是文件大小要大于等于一帧 framebuffer 大小。240x320 分辨率、RGB5652 字节/像素的一帧数据是240 * 320 * 2 153600字节。如果图片文件小于这个值屏幕只会被填满一部分如果大于一般问题也不大多出的部分会被截断。还有一个值得试的方法是先生成一个纯色 raw 文件验证颜色格式dd if/dev/urandom of/dev/fb0 bs153600 count1屏幕上如果出现满屏雪花说明 RGB565 数据通道是通的颜色随机变化也正常。如果花屏、横向条纹、颜色错乱问题大概率出在像素格式或者分辨率设置上而不是屏幕物理损坏。4.3 在 GUI 框架里显示图片如果项目要跑 Qt、LVGL 或者其他 GUI显示图片就更是常规操作了。Qt 下只需要把显示后端切到 DRM 或 EGLFSexport QT_QPA_PLATFORMeglfs export QT_QPA_EGLFS_INTEGRATIONeglfs_kms ./my_qt_appLVGL 在 Linux 上的移植也比较成熟底层有drm或fbdev两种驱动接口只需要提供flush_cb回调把 LVGL 的绘制缓冲提交给 DRM framebuffer 即可。这时候你再想想“取模”是不是已经完全用不上了不过这里有一个容易踩的坑在 240x320 的 SPI 屏上跑 GUI性能瓶颈不在 CPU而在 SPI 带宽。如果你做全屏刷新动画比如页面切换、滑动列表帧率基本只有十几 FPS 甚至更低。解决思路不是优化 GUI 代码而是减少刷新面积或者升级到 RGB/LVDS 接口屏幕。这个问题我们放到下一节详细算笔账。5. 常见问题与调试实录5.1 白屏、黑屏最先怀疑哪几个点白屏、黑屏是 ST7789v 接入 DRM 后最常碰到的现象通常不是驱动逻辑问题而是硬件配置或初始化时序问题。我把排查顺序固定下来遇到问题照着走能省很多时间。第一看背光有没有亮。如果背光完全不亮屏幕当然黑但这和面板驱动无关。检查gpio-backlight节点对应 GPIO 是否输出高电平或者用万用表量一下 BLK 引脚电压。第二看复位引脚时序。ST7789v 的复位要求低电平保持若干毫秒、再拉高很多模块如果复位信号悬空或者乱跳上电后 IC 可能处于未初始化状态。用 GPIO 控制复位时检查设备树里reset-gpios是不是真正的复位脚极性是否正确。有些模块的 RESET 是低有效写错了驱动看起来执行了复位实际没有。第三看 SPI 的dc-gpios。这一点特别容易漏。如果 DC 线没有接对ST7789v 会把像素数据当成命令执行结果就是屏幕背光亮、但没有图像或者显示一团乱码。用modetest -f出测试图案时如果一直是纯色没有变化优先查 DC 线。第四看 SPI 时钟模式。ST7789v 模块一般支持 SPI Mode 0 或 Mode 2具体要看模块厂家。DRM 的 MIPI DBI 框架默认使用 SPI Mode 0如果你的模块必须 Mode 2可能需要在内核驱动里额外配置或者用spi-cpol、spi-cpha设备树属性。当时这块屏在 Mode 0 下是正常的但不同模块确实可能不一样。我建议的排查顺序是背光 – 复位 – DC – SPI 模式 – 驱动匹配前四项基本能覆盖 80% 的黑屏问题。5.2 颜色不对、花屏和偏移问题如果屏幕能亮但显示出来的颜色和预期完全不同比如红蓝交换、颜色发青、偏色严重大概率是像素格式不匹配。ST7789v 本身支持 RGB565、RGB666 等格式DRM 驱动默认按 RGB565 输出。你在modetest -s或者 fb 写入时要确保每像素字节数和顺序一致。用 fb 测试时rgb565le是小端 RGB565和内核 framebuffer 的默认格式一致。如果用rgb565be或者 RGB888颜色就会明显错乱。花屏还有一种常见原因屏幕模块的偏移量。很多贴了 ST7789v IC 的屏幕实际显示区域并不是从 IC 内部 RAM 的(0,0)开始而是有一个偏移。比如某些 2.0 寸屏需要x-offset0, y-offset32才显示在正确位置。DRM 驱动里一般把这些偏移量写在st7789v_panel_info或者设备树中。如果你的屏幕显示内容整体偏移、上下左右被切割不要怀疑屏幕坏了去查驱动的偏移配置。另外rotation参数设置错误也会造成显示方向异常180 度颠倒只是美观问题但 90 度方向导致的分辨率互换240x320 变成 320x240可能让扫描区域和显存不匹配表现为花屏。这里可以四个方向都试一遍找出和物理贴合的那个值。5.3 刷新率低、撕裂感怎么优化先算一笔账。240x320、RGB565一帧原始数据是 153600 字节。如果 SPI 时钟是 20MHz最乐观情况每秒最多传 20Mbit / 8 2.5MB实际还要去掉命令、等待、控制位开销有效带宽按 80% 算就是 2MB/s 左右。那全屏刷新率就是2MB / 150KB ≈ 13fps。这个帧率跑静态界面没问题跑动画就很吃力。之前提到过如果全是 SPI再怎么优化驱动也无法突破物理带宽。想提升流畅度有几种实际可用的思路提高 SPI 时钟频率。从 20MHz 提到 40MHz理论帧率能翻倍但如果杜邦线太长容易出错可能需要改用短排线或 PCB 直连。减少刷屏区域。很多场景只需要更新屏幕上的一小块区域DRM 的 plane 可以只提交局部 dirty 区域通知面板驱动做部分刷新。不过这依赖硬件和驱动的能力ST7789v 驱动不一定支持 partial update需要改驱动或结合 MIPI DBI 的dirtyfb接口。换 RGB565 为 RGB222 或减少颜色深度。颜色信息少了一半数据量也少一半但显示效果会打折。如果项目对流畅度要求高干脆放弃 SPI 屏换成 RGB 并口屏或 MIPI DSI 屏。MP257F-DK 本身有 DSI/LVDS 接口带宽根本不是一个量级。撕裂感通常是双缓冲或多缓冲没开。DRM 下可以用DRM_MODE_PAGE_FLIP_FLIP做 page flip 同步配合垂直同步信号。但 ST7789v 这种 SPI 屏本身没有硬件 VBLANK 概念DRM 的 vblank 模拟能力有限所以 page flip 只能做到“串行提交”不能真正同步刷新。实际项目里如果是纯静态 UI撕裂感基本可以忽略如果一定要跑动画那就是硬件选型问题。5.4 一个可复用的 DRM 初始化检查清单调试 DRM 设备时我喜欢按下面的清单逐项确认很多问题都能快速定位。dmesg | grep -i st7789驱动是否 probe 成功。如果没有任何打印先看 compatible 匹配和设备树节点状态。ls -l /dev/dri/DRM 设备节点是否存在。没有节点说明内核里 DRM 框架没初始化。modetest -M stm -cconnector 是否枚举出来mode 列表是否包含 240x320。modetest -M stm -s connector:240x320实际连接输出是否正常屏幕能不能显示测试图案。fbset -fb /dev/fb0fbdev 模拟层是否正常工作分辨率、像素格式是否符合预期。weston --backenddrm-backend.so真实合成器是否能在该面板上输出。这套检查顺序从底层到上层每过一步就能排除一类问题。我每次在嵌入式 Linux 上接新屏都会先用这个流程把“物理链路是否通”和“上层合成是否正常”分开避免在应用层排查了半天最后发现是设备树 pinmux 错了。再补充一个小技巧调rotation和偏移量时不要每次改完设备树都重新烧写整机可以先把屏幕显示一个网格或者数字比如用modetest的测试图案或者用 fb 写一张带坐标刻度的 BMP这样能直观看出旋转和偏移是否合适。我通常会在屏幕中央画一个大十字四个角画不同颜色的小方块这样哪个方向错了一眼就能看出来。在实际操作中我对这个项目最深的体会是ST7789v 这种小屏在廉价的 MCU 方案里是“配置寄存器 刷显存”的体力活但到了 Linux 端真正决定它能不能用的不是屏幕本身而是你有没有把它正确地接入系统已有的显示框架。只要 DRM 设备树配置对了、驱动加载了这块屏就变成了和 HDMI 一样的标准显示输出后续所有图形开发都不需要再关心屏幕的物理接口。如果你也正在 MP2 或者其他嵌入式 Linux 平台上挂这类 SPI 小屏希望这篇文章能帮你少走几步弯路。特别是设备树里dc-gpios、reset-gpios和rotation这几个属性八成以上点不亮的问题都出在这三处先把它们确认好再谈上层合成和性能优化。