Support Linux DRM backend

[Bennctu]

Currently, using the DRM legacy interface is suitable for Mado's backend because we only need basic window display without advanced features.

[huaxinliao]

I'm confused about this. It should be as below.

/* Retrieve resources */
if (!get_resources(tx->drm_dri_fd, &RES(tx)))
    goto bail_res;
....
bail_fb:
    drmModeRmFB(tx->drm_dri_fd, tx->fb_id);
    munmap(tx->fb_base, tx->fb_len);
bail_crtc:
    drmModeFreeCrtc(CRTC(tx));
bail_conn:
    drmModeFreeConnector(CONN(tx));
bail_res:
    drmModeFreeResources(RES(tx));

[jserv]

Check the DRM implementation for reference: https://github.com/zlgopen/awtk-linux-fb/blob/master/awtk-port/lcd_linux/lcd_linux_drm.c

[huaxinliao]

I consider that twin_drm_exit should handle ioctl(tx->drm_dri_fd, DRM_IOCTL_MODE_DESTROY_DUMB, &destroy) to ensure allocated resources are properly released.

[jserv]

For mado, a libdrm-free DRM backend is realistic because the use caseonly needs KMS + dumb buffer + CPU rendering, not GBM/EGL/GPU rendering. This pull request currently uses libdrm helpers such as drmModeGetResources, drmModeGetConnector, drmModeAddFB, drmModeSetCrtc, and drmModeRmFB, while already using raw ioctls for dumb-buffer creation/mapping.

The dumb-buffer path is appropriate: DRM dumb buffers are CPU-mappable scanout buffers, suitable for simple rendering but not complex GPU composition. GETCONNECTOR is intentionally a two-pass ioctl: first retrieve counts, then allocate arrays and retrieve modes/encoders; hotplug can race, so retry until counts stabilize.

Minimal ioctl-only framebuffer sequence is shown below:

open("/dev/dri/card0", O_RDWR | O_CLOEXEC);

DRM_IOCTL_MODE_GETRESOURCES;
DRM_IOCTL_MODE_GETCONNECTOR;   /* two-pass */
DRM_IOCTL_MODE_GETCRTC;

DRM_IOCTL_MODE_CREATE_DUMB;
DRM_IOCTL_MODE_ADDFB2;
DRM_IOCTL_MODE_MAP_DUMB;
mmap();

DRM_IOCTL_MODE_SETCRTC;

Use legacy SETCRTC first, not atomic KMS. Atomic is cleaner long-term, but it requires property discovery and more code. For mado’s CPU-rendered full-screen backend, direct legacy KMS ioctls are the smallest maintainable step.

[Bennctu]

I ran the DRM backend on a VM with Ubuntu 24.04. However, I noticed that the screen froze.
drm.mov

I verified that the DRM backend runs successfully on Ubuntu 24.04 VM.

Screencast.from.2026.02.00.56.24.webm

[huaxinliao]

I'm curious which part of the code fixed the VM issue.

[huaxinliao]

Currently, using the DRM legacy interface is suitable for Mado's backend because we only need basic window display without advanced features.

Hi @Bennctu, Also, does commit e4f93e9 show the same rendering result as this one? I’d like to learn more about this part as well. Thank you for your generous explanation!

[cubic-dev-ai]

1 issue found across 5 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="configs/Kconfig">

<violation number="1" location="configs/Kconfig:81">
P2: `BACKEND_DRM` is missing a dependency gate for libdrm, so users can enable it in Kconfig and hit build failures on systems without libdrm installed.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: BACKEND_DRM is missing a dependency gate for libdrm, so users can enable it in Kconfig and hit build failures on systems without libdrm installed.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At configs/Kconfig, line 81:

<comment>`BACKEND_DRM` is missing a dependency gate for libdrm, so users can enable it in Kconfig and hit build failures on systems without libdrm installed.</comment>

<file context>
@@ -76,6 +76,15 @@ choice
 
+config BACKEND_DRM
+    bool "Linux DRM support"
+    depends on !CC_IS_EMCC
+    select CURSOR
+    help
</file context>