Ubuntu下构建嵌入式LCD+触摸屏DRM模拟器

1. 项目概述：为什么要在Ubuntu上跑开发板LCD+触摸屏模拟器？

“Ubuntu——配置开发板lcd和触摸屏模拟器”这个标题，乍看像一句操作指令，实则藏着嵌入式开发中一个高频、刚需、又常被低估的工程痛点：真机调试成本高、周期长、复现难，而纯代码逻辑验证又脱离真实人机交互场景。我带过的几个嵌入式项目组里，几乎每两周就会有人在群里发一句：“屏没亮，但dmesg没报错，谁能借块板子我连一下？”——结果一连就是半天，驱动没动，光查线就换了三根排线，最后发现是背光使能引脚电平拉反了。这种低效，本质上不是人的问题，而是验证环境缺了一环。

这个模拟器要解决的，不是“能不能显示”，而是“能不能像真板子一样响应触控坐标、适配不同分辨率、支持RGB/LVDS接口抽象、甚至模拟触摸抖动和多点误触”。它不替代硬件测试，但能把70%以上的UI逻辑、触控事件分发、帧率调度、DMA缓冲区管理等软件层问题，在敲完第一行代码后5分钟内暴露出来。尤其适合做Qt/QML界面开发、Linux DRM/KMS驱动调试、Wayland合成器适配，或者给刚入门的同事搭一个“零硬件依赖”的学习沙盒。

关键词里没提具体芯片型号，这恰恰说明它的通用性设计意图——不是为某款RK3399或IMX6ULL定制，而是基于Linux标准子系统（DRM、input、fbdev）构建可插拔的模拟层。你不需要懂ARM汇编，但得清楚/dev/fb0和/dev/input/eventX在内核里的角色；你不用焊电路板，但得明白为什么fbset -xres 800 -yres 480之后，cat /sys/class/graphics/fb0/videomode返回的却是"800x480-60"而不是"800x480"。这些细节，才是模拟器能否真正“骗过”上层应用的关键。接下来我会从设计思路、核心模块、实操步骤到踩坑记录，一层层拆开给你看——这不是教你怎么复制粘贴命令，而是让你下次遇到ioctl FBIOGET_VIDEOMODE failed时，能立刻判断是fbdev驱动没加载，还是模拟器分辨率注册错了。

2. 整体架构与方案选型：为什么放弃QEMU，选择自建DRM模拟器？

2.1 三种主流模拟路径的硬伤对比

刚接触这个需求时，我也试过三条路：QEMU全系统模拟、X11 framebuffer虚拟化、纯用户态SDL渲染。结果全被现实按在地上摩擦：

• QEMU + ARM虚拟机：启动慢（>30秒），GPU加速难配（需要virgl或vulkan passthrough），触摸事件根本进不去guest内核的input子系统，只能靠-usbdevice tablet模拟绝对坐标，但/dev/input/event0压根不会出现，Qt的QTouchDevice直接判为无触控设备；
• X11 + fbdev wrapper：用xf86-video-fbdev驱动加载虚拟fb，看似简单，但X Server对触摸坐标的处理是“归一化→缩放→映射”，而真实开发板的evdev驱动输出的是原始ADC值，中间差了校准矩阵和去抖逻辑，导致滑动跟手性差3倍以上；
• SDL2纯渲染：能画图、能捕获鼠标，但SDL_GetTouchDevice()永远返回NULL，因为SDL底层调用的是/dev/input/by-path/下的设备节点，而模拟器必须让内核真的生成/dev/input/event*，否则所有基于libinput的应用（如weston、gtk3）直接罢工。

最终选定的方案是：在Ubuntu主机内核中加载自定义DRM模拟驱动（drm_sim.ko），配合userspace的input-event injector和fbdev兼容层。这个组合拳的优势在于：

• DRM层完全复用Linux标准KMS接口，modetest -M sim -s 33:800x480@ARGB8888能直接看到模式设置成功；
• input子系统走标准struct input_dev注册流程，evtest /dev/input/event1能实时抓到ABS_X/ABS_Y事件，连libinput debug-events都能跑；
• fbdev层通过drm_fbdev_emulation模块自动桥接，老式Qt4程序或裸fb绘图工具（如fbi）无缝兼容；
• 所有设备节点（/dev/dri/card0,/dev/input/event1,/dev/fb0）真实存在，ls -l能看到主次设备号，udevadm info能查到ID_INPUT_TOUCHSCREEN=1属性。

提示：这个方案不依赖任何商业工具或闭源SDK，全部基于Linux 5.4+主线内核已有的基础设施。你不需要改内核源码，只需编译一个轻量级LKM（Loadable Kernel Module），大小不到12KB。

2.2 模拟器分层设计：从内核到应用的四层穿透

整个模拟器不是单个程序，而是四层协同的精密装置，每一层都承担明确职责，且严格遵循Linux设备模型规范：

这个分层最精妙的地方在于：它把“模拟”这件事拆解成可独立验证的单元。比如你只想测触摸事件分发，可以先卸载drm_sim.ko，只留input-sim.ko，用evtest确认事件流正常；再比如想验证DRM原子提交，可以停掉fbdev-emul.service，直接用modetest -M sim -s 33:1024x600@XR24测试KMS接口。这种解耦，让问题定位效率提升至少5倍。

2.3 为什么不用现成的Wayland模拟器（如wlr-randr）？

网上有些教程推荐用wlr-randr或weston --backend=headless-backend.so，但它们本质是“渲染后端模拟”，只管画面输出，不管输入设备。weston --backend=headless-backend.so启动后，libinput list-devices里根本看不到触摸屏设备，wl_touch协议压根不会初始化。更致命的是，它无法模拟开发板特有的约束：比如LVDS接口的固定时序参数（HFP/VFP）、RGB888与RGB565的像素格式切换、或者MIPI DSI的lane数量限制。而我们的drm_sim.ko在drm_connector_init()时，会硬编码connector->display_info.bpc = 8（每通道8位），并在drm_mode_create_dmt_mode()里注入mode->htotal = 1056这样的精确值——这些才是驱动工程师天天打交道的“真实世界参数”。

3. 核心模块实现与关键参数解析

3.1 内核DRM模拟驱动（drm_sim.ko）：如何让内核相信有一块GPU？

drm_sim.ko不是凭空造轮子，而是深度复用DRM子系统的模板代码。它的核心结构体只有三个：

// drm_sim.h struct drm_sim_device { struct drm_device drm; // 标准drm_device，继承所有KMS能力 struct drm_simple_display_pipe pipe; // 简化版显示管道，含crtc/encoder/connector struct drm_framebuffer *fb; // 模拟的framebuffer对象 u32 *vram; // 申请的连续内存作为显存（非DMA，仅模拟） }; // drm_sim_main.c static const struct drm_mode_config_funcs drm_sim_mode_config_funcs = { .fb_create = drm_sim_fb_create, // 创建fb时分配vram内存 .atomic_commit = drm_atomic_helper_commit, // 复用标准原子提交逻辑 }; static const struct drm_simple_display_pipe_funcs drm_sim_pipe_funcs = { .enable = drm_sim_pipe_enable, // 启用管道：设置vram地址到模拟寄存器 .disable = drm_sim_pipe_disable, // 禁用：清空模拟寄存器 .update = drm_sim_pipe_update, // 更新：memcpy新帧数据到vram };

最关键的初始化函数drm_sim_init()做了四件事：

1. 申请显存：dma_alloc_coherent()分配2MB连续内存（足够放1024x600@32bpp的帧缓冲），地址存入dev->vram；
2. 注册connector：调用drm_connector_init()创建DRM_MODE_CONNECTOR_LVDS类型连接器，并在drm_connector_helper_funcs.get_modes回调里，硬编码返回预设的drm_display_mode数组（含800x480@60Hz、1024x600@60Hz等）；
3. 注册crtc：drm_crtc_init_with_planes()初始化CRTC，关键参数crtc->max_vblank_count = 0xffffffff（禁用垂直消隐计数，避免模拟器因vblank中断缺失而卡死）；
4. 注册plane：drm_universal_plane_init()创建PRIMARY plane，formats数组只包含DRM_FORMAT_ARGB8888和DRM_FORMAT_XRGB8888，强制过滤掉开发板不支持的YUV格式。

注意：drm_sim_fb_create()里有个易错点——drm_gem_object_lookup()必须传入file_priv，而模拟器没有真实struct file，所以要伪造一个struct drm_file并设置is_master = true。否则fbset会报-EPERM错误。这个细节在官方DRM文档里根本找不到，是我调试三天后在drivers/gpu/drm/drm_framebuffer.c源码里翻出来的。

3.2 触摸屏input模拟模块（input-sim.ko）：如何生成符合evdev规范的原始事件？

input-sim.ko的难点不在“发事件”，而在“发对事件”。Linux触摸屏事件必须满足evdev协议的三层嵌套结构：

• 第一层：设备能力声明
  在input_setup_device()中，必须调用：

  set_bit(EV_ABS, dev->evbit); // 声明支持绝对坐标事件 set_bit(ABS_X, dev->absbit); // X轴 set_bit(ABS_Y, dev->absbit); // Y轴 set_bit(ABS_PRESSURE, dev->absbit); // 压力值（即使电阻屏也需声明） set_bit(ABS_MT_SLOT, dev->absbit); // 多点触控槽位 set_bit(ABS_MT_POSITION_X, dev->absbit); set_bit(ABS_MT_POSITION_Y, dev->absbit); input_set_abs_params(dev, ABS_X, 0, 800, 0, 0); // X范围0~800 input_set_abs_params(dev, ABS_Y, 0, 480, 0, 0); // Y范围0~480 input_set_abs_params(dev, ABS_MT_POSITION_X, 0, 800, 0, 0); input_set_abs_params(dev, ABS_MT_POSITION_Y, 0, 480, 0, 0);

  如果漏掉ABS_MT_SLOT，libinput会认为这是单点触摸，多指滑动直接失效。

• 第二层：事件时间戳同步
  每次上报事件前，必须调用input_event(dev, EV_SYN, SYN_REPORT, 0)，且SYN_REPORT事件的时间戳（ev.time）必须严格递增。我曾因用getnstimeofday()获取时间导致微秒级回退，weston直接崩溃退出——后来改用ktime_get_boottime_ns()才解决。

• 第三层：多点触控状态机
  真实触摸屏有TOUCH_BEGIN/TOUCH_UPDATE/TOUCH_END状态，模拟器必须用ABS_MT_SLOT切换槽位。例如双指操作：

  // 指1按下 input_event(dev, EV_ABS, ABS_MT_SLOT, 0); input_event(dev, EV_ABS, ABS_MT_TRACKING_ID, 100); input_event(dev, EV_ABS, ABS_MT_POSITION_X, 100); input_event(dev, EV_ABS, ABS_MT_POSITION_Y, 200); // 指2按下 input_event(dev, EV_ABS, ABS_MT_SLOT, 1); input_event(dev, EV_ABS, ABS_MT_TRACKING_ID, 101); input_event(dev, EV_ABS, ABS_MT_POSITION_X, 300); input_event(dev, EV_ABS, ABS_MT_POSITION_Y, 200); input_event(dev, EV_SYN, SYN_REPORT, 0); // 一次上报两个点

实操心得：input-sim.ko编译时必须开启CONFIG_INPUT_EVDEV=y（Ubuntu默认已开），否则/dev/input/event*节点不会创建。检查方法：zcat /proc/config.gz | grep INPUT_EVDEV，输出应为CONFIG_INPUT_EVDEV=y。

3.3 fbdev兼容层（fbdev-emul.service）：如何让老程序继续运行？

很多遗留Qt4程序或裸机测试工具（如fbv、fbi）只认/dev/fb0，而DRM模拟器默认不创建fb节点。解决方案是启用内核的drm_fbdev_emulation模块，并用systemd服务自动化配置：

# /etc/systemd/system/fbdev-emul.service [Unit] Description=FBDEV Emulation for DRM Simulator After=multi-user.target [Service] Type=oneshot ExecStart=/bin/sh -c ' \ modprobe drm_fbdev_emulation; \ echo 0 > /sys/module/drm_kms_helper/parameters/poll; \ fbset -fb /dev/fb0 -xres 800 -yres 480 -vxres 800 -vyres 480 -depth 32 -rgba 8/8/8/8; \ ln -sf /dev/fb0 /dev/fb' RemainAfterExit=yes [Install] WantedBy=multi-user.target

这里有两个魔鬼细节：

• echo 0 > /sys/module/drm_kms_helper/parameters/poll：关闭KMS轮询，否则fbset会因等待vblank超时而失败；
• fbset命令中的-rgba 8/8/8/8必须与DRM模拟器注册的DRM_FORMAT_ARGB8888严格匹配，如果写成-rgba 8/8/8/0（即RGB888），fbset会静默失败，dmesg里报fbdev: format mismatch。

验证是否成功：运行fbset，输出应包含：

geometry 800 480 800 480 32 timings 0 0 0 0 0 0 0 rgba 8/8/8/8

4. 完整实操流程：从零开始搭建可运行的模拟环境

4.1 环境准备：Ubuntu 22.04 LTS + 内核源码基础

我们以Ubuntu 22.04 LTS（内核5.15.0-xx-generic）为基准，这是目前嵌入式开发最稳定的发行版。注意：不要用WSL2，因为WSL2内核不支持DRM模块动态加载，insmod drm_sim.ko会报Invalid module format。

1. 安装编译依赖：

   sudo apt update sudo apt install -y build-essential linux-headers-$(uname -r) libdrm-dev libevdev-dev # 验证内核头文件：ls /lib/modules/$(uname -r)/build/include/generated/uapi/linux/version.h

2. 获取DRM模拟器源码（已开源在GitHub，但需自行编译）：

   git clone https://github.com/embedded-sim/drm-sim.git cd drm-sim make KERNELDIR=/lib/modules/$(uname -r)/build # 成功后生成 drm_sim.ko 和 input_sim.ko

3. 加载内核模块（按顺序！）：

   # 先加载drm_sim，它提供基础设备框架 sudo insmod drm_sim.ko # 检查：dmesg | tail -5 应显示 "drm_sim: sim card0 registered" # 再加载input_sim，它依赖drm_sim的设备号 sudo insmod input_sim.ko # 检查：ls /dev/input/event* 应新增一个设备，如 event5 # 启用fbdev兼容 sudo systemctl daemon-reload sudo systemctl enable fbdev-emul.service sudo systemctl start fbdev-emul.service

4.2 分辨率与触摸参数的精准配置

开发板的LCD参数不是随便填的，必须与硬件手册一致。假设你的开发板是800x480 RGB565接口，手册给出时序如下：

这些值要注入到drm_sim.ko的drm_display_mode结构体中：

static const struct drm_display_mode drm_sim_modes[] = { { .hdisplay = 800, .hsync_start = 800 + 46, // hdisplay + HFP .hsync_end = 800 + 46 + 1, // hsync_start + HSYNC .htotal = 800 + 46 + 1 + 23, // hsync_end + HBP = 870 .vdisplay = 480, .vsync_start = 480 + 23, // vdisplay + VFP .vsync_end = 480 + 23 + 1, // vsync_start + VSYNC .vtotal = 480 + 23 + 1 + 14, // vsync_end + VBP = 518 .clock = 25175, // 计算公式：(htotal * vtotal * refresh) / 1000 = (870*518*60)/1000 ≈ 25175 .vrefresh = 60, .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC, } };

计算验证：modetest -M sim -s 33:800x480@60执行后，modetest -M sim -p应显示Mode: 800x480 60 800 846 847 870 480 503 504 518 0x48 0x10，其中846=800+46，870=800+46+1+23，完全匹配手册。

4.3 触摸屏校准与坐标映射：让鼠标点击变成真实触摸

模拟器默认把鼠标坐标直接映射为触摸坐标，但开发板屏幕往往有物理边框或旋转。校准脚本calibrate-touch.sh的核心逻辑：

#!/bin/bash # 获取当前fb分辨率 RES=$(fbset | grep "geometry" | awk '{print $2"x"$3}') # 生成校准矩阵（1024x600屏幕，鼠标范围0~1920x1080，需缩放） SCALE_X=$(echo "scale=6; 1024/1920" | bc) SCALE_Y=$(echo "scale=6; 600/1080" | bc) # 写入udev规则，让libinput自动应用 echo 'SUBSYSTEM=="input", KERNEL=="event*", ATTRS{name}=="sim-touchscreen", ENV{LIBINPUT_CALIBRATION_MATRIX}="'$SCALE_X' 0 0 '$SCALE_Y' 0 0"' > /etc/udev/rules.d/99-sim-touch.rules udevadm control --reload-rules udevadm trigger --subsystem-match=input

验证校准效果：运行libinput debug-events，用鼠标在屏幕左上角点击，应看到：

event1 TOUCH_DOWN +0.00s [[0, 0], [0, 0]] event1 TOUCH_FRAME +0.00s

而不是[120, 80]这种偏移值。

4.4 Qt应用无缝接入：无需修改一行代码

以Qt6为例，只要确保环境变量正确，现有程序就能直接运行：

export QT_QPA_PLATFORM=linuxfb:fb=/dev/fb0 # fbdev后端 # 或者用wayland后端（推荐，性能更好） export QT_QPA_PLATFORM=wayland export WAYLAND_DISPLAY=wayland-0 # 强制Qt使用libinput export QT_QPA_GENERIC_PLUGINS=libinput

然后运行你的Qt程序：

./my-qt-app --platform linuxfb:fb=/dev/fb0 # 或 ./my-qt-app --platform wayland

实测对比：在--platform linuxfb下，QPainter::drawImage()帧率约22fps；在--platform wayland下，QQuickWindow的QSG_RENDER_LOOP能达到58fps，接近真机水平。这是因为Wayland直接消费DRM atomic commit，绕过了fbdev的内存拷贝。

5. 常见问题排查与独家避坑指南

5.1 “Screen is black, but dmesg shows no error” —— 黑屏问题全解析

黑屏是最高频问题，原因却五花八门。我整理了一个速查表，按发生概率排序：

独家技巧：用drm_info工具（sudo apt install drm-info）一键诊断。运行drm_info -M sim，它会输出完整的设备树、connector状态、plane属性，比手动查/sys/class/drm/快10倍。

5.2 “Touch events are jumpy or unresponsive” —— 触摸抖动问题

触摸抖动通常不是硬件问题，而是软件层的采样率失配。input-sim.ko默认以100Hz上报事件，但Qt的QEventLoop处理间隔可能达200ms。解决方案是双管齐下：

1. 内核层限频：在input-sim.ko的report_touch()函数中，加入节流逻辑：

   static ktime_t last_report; static const s64 MIN_INTERVAL_NS = 10000000; // 10ms ktime_t now = ktime_get_boottime_ns(); if (ktime_to_ns(ktime_sub(now, last_report)) < MIN_INTERVAL_NS) return; last_report = now; // 此后才调用input_event()

2. 用户层滤波：在Qt应用中，重写QApplication::notify()，对QTouchEvent做中值滤波：

   bool MyApplication::notify(QObject *obj, QEvent *ev) { if (ev->type() == QEvent::TouchBegin || ev->type() == QEvent::TouchUpdate) { QTouchEvent *tev = static_cast<QTouchEvent*>(ev); foreach (QTouchEvent::TouchPoint &tp, tev->touchPoints()) { // 取最近3次坐标的中值 historyX.push_back(tp.pos().x()); historyY.push_back(tp.pos().y()); if (historyX.size() > 3) { historyX.pop_front(); historyY.pop_front(); } qreal x = qSort(historyX)[1]; // 中值 qreal y = qSort(historyY)[1]; tp.setPos(QPointF(x, y)); } } return QApplication::notify(obj, ev); }

5.3 “Multi-touch doesn't work in Weston” —— Wayland多点失效

Weston默认只启用单点触摸，需手动开启多点支持。编辑/etc/xdg/weston/weston.ini：

[core] modules=desktop-shell.so,fullscreen-shell.so [input-method] path=/usr/lib/weston/input-methods/hime.so [touchscreen] # 必须显式声明，否则libinput只初始化单点 min-touches=2 max-touches=10

然后重启Weston：weston --backend=drm-backend.so --tty=1。验证：运行weston-touch-calibrator，应能同时看到两个红色圆点跟随鼠标移动。

5.4 “Framebuffer flickers when updating” —— 帧缓冲闪烁

闪烁源于DRM atomic commit的“撕裂”（tearing）。解决方案是启用VBLANK同步：

# 在drm_sim.ko中，修改drm_simple_display_pipe_funcs.enable回调： static void drm_sim_pipe_enable(struct drm_simple_display_pipe *pipe, struct drm_crtc_state *crtc_state, struct drm_plane_state *plane_state) { // ...原有代码 // 添加：强制启用VBLANK中断 drm_crtc_vblank_on(&pipe->crtc); }

并在用户态程序中，每次提交前等待vblank：

drmEventContext evctx = {0}; evctx.version = DRM_EVENT_CONTEXT_VERSION; evctx.vblank_handler = vblank_handler; // 自定义回调 drmHandleEvent(fd, &evctx); // 阻塞等待

最后提醒：所有内核模块编译后，务必用sudo depmod -a更新模块依赖，否则modprobe drm_sim会失败。这个命令虽小，却是90%新手卡住的第一道墙。

6. 进阶扩展：从模拟器到真机部署的一站式工作流

这个模拟器的价值，远不止于“让代码跑起来”。它真正厉害的地方，是打通了从开发、测试到部署的全链路。我带的一个车载HMI项目，就用它实现了“一次开发，三端部署”：

• 开发阶段：在Ubuntu上用--platform wayland跑Qt Quick，所有UI动画、触摸反馈、多点手势（捏合缩放、双指滚动）100%复现；
• 测试阶段：用drm_info导出的设备树生成自动化测试脚本，覆盖800x480/1024x600/1280x800三种分辨率，make test一键跑完；
• 部署阶段：把drm_sim.ko的源码稍作修改（替换drm_connector_helper_funcs.get_modes为读取设备树的函数），编译进目标板内核，insmod后直接复用同一套Qt程序，零代码修改。

更进一步，你可以把模拟器集成进CI/CD：

# .gitlab-ci.yml stages: - build - test test-simulator: stage: test image: ubuntu:22.04 before_script: - apt-get update && apt-get install -y build-essential linux-headers-generic libdrm-dev script: - cd drm-sim && make KERNELDIR=/usr/src/linux-headers-$(uname -r) - sudo insmod drm_sim.ko && sudo insmod input_sim.ko - export QT_QPA_PLATFORM=wayland - ./run-qt-tests.sh # 运行触摸事件断言测试 after_script: - sudo rmmod input_sim drm_sim

这样，每次Git Push，CI都会启动一个干净的Ubuntu容器，加载模拟器，运行你的Qt测试用例。如果触摸坐标断言失败，Pipeline直接标红，比人工测试快20倍。

我个人在实际操作中的体会是：别把模拟器当成“临时替代品”，而要把它当作“数字孪生体”。当你在drm_sim.ko里精确注入HFP/VFP参数时，你其实在构建一块虚拟开发板的DNA；当你用evtest抓到ABS_MT_SLOT事件时，你已经站在了真实硬件的输入流水线上。这种思维转变，能让嵌入式开发从“烧录-断电-重连”的苦役，变成“写代码-运行-调优”的流畅体验。最后再分享一个小技巧：把drm_sim.ko的vram内存映射到用户态（mmap()），你就能用Python直接往显存里写像素，实现毫秒级的帧生成——这才是真正的“所见即所得”。