Linux下通过DRM操作屏幕，发生行对齐 (stride)问题

前言

Linux下使用LVGL操作屏幕，屏幕尺寸是[280*1424]，不管如何设置LVGL的参数，屏幕的显示均为花屏，能看到有图像显示，但是图像是行错乱的。

ubuntu桌面系统显示正常

打印DRM看输出

drm: 280x1424 (0mm X 0mm) pixel format AR24

可见DRM的没什么问题，确实和屏幕对的上

使用色块填充排查

给屏幕直接填充固定颜色

cpp 复制代码

    // 填充为红色（例如 ARGB8888 格式：0xFFFF0000）
    uint32_t *fb = (uint32_t *)fbuf->map;

    int i;
    for(i = 0; i < 280*2; i++)
    {
        fb[i] = 0xFFFF0000; // 红色像素值
        // for(int j = 0; j < 100; j++)
        // {
        //     fb[i*1424 + j] = 0xFFFF0000; // 红色像素值
        // }
    }
    for(; i < 280*1424; i++)
    {
        fb[i] = 0xFF00FF00; // 绿色像素值
    }

发现问题：一行似乎不是280个像素点。每行的似乎在285~290之间？

分析

出现这种情况的原因可能与 屏幕的行对齐方式（stride） 或 缓冲区分辨率设置 不一致有关。虽然屏幕的逻辑分辨率是 1424x280 ，但 一行的实际像素数量可能大于 1424 ，这是由于 行对齐 或 缓冲区分配方式 的限制。

行对齐 (stride)：
- 大多数 GPU 或显示硬件要求每行的像素数据对齐到特定的字节边界（如 32 字节或 64 字节）。
- 即使屏幕宽度是 1424 像素，每行数据的实际占用可能大于 1424 ***** 4 字节。
- 这个实际的宽度称为 stride（步长），通常可以通过 DRM 查询到。
缓冲区的 stride 不匹配：
- 如果你直接按分辨率 1424 * 280 计算缓冲区的大小，可能会忽略 stride 的额外字节。
- 例如，stride 可能是 **1440 * 4**字节，即一行的实际长度为 1440 像素（即便只显示 1424 像素）。
显存分配方式：
- 显存分配时可能会对分辨率进行对齐操作，比如将宽度对齐到 8 或 16 的倍数，导致一行像素的数量超过逻辑宽度。

cpp 复制代码

drm: 280x1424 (0mm X 0mm) pixel format AR24
drm: pitch 1152
drm: size 1640448
drm: pitch 1152
drm: size 1640448
DRM subsystem and buffer mapped successfully

解析打印信息

分辨率：
- drm: 280x1424 表示屏幕的逻辑分辨率为宽 280 像素，高 1424 像素。
像素格式：
- pixel format AR24 表示屏幕的像素格式为 XRGB8888 ，即每像素占用 4 字节（32 位），Alpha 通道未使用。
Pitch (stride)：
- drm: pitch 1152 表示每行像素占用 1152 字节。
- 对于 XRGB8888 ，每像素占用 4 字节，因此一行实际包含 1152 / 4 = 288 像素。
- 这是由于硬件对行数据进行了 对齐处理（对齐到 32 字节或 64 字节）。
缓冲区大小：
- drm: size 1640448 表示缓冲区总大小为 1640448 字节。
- 计算：pitch * height = 1152 * 1424 = 1640448 字节。这与打印的大小一致。