STRUCT DRM_FB_HELPER(9)

✨ struct drm_fb_helper(9) ✨

okay so bestie, this is from the Kernel API Manual and it's literally the whole personality of fbdev emulation on top of KMS 💅

---

🎀 NAME 🎀

struct drm_fb_helper — the main structure to emulate fbdev on top of KMS. that's it, that's the vibe 🦋

---

🌸 SYNOPSIS 🌸

struct drm_fb_helper {
    struct drm_client_dev client;
    struct drm_client_buffer *buffer;
    struct drm_framebuffer *fb;
    struct drm_device *dev;
    const struct drm_fb_helper_funcs *funcs;
    struct fb_info *info;
    u32 pseudo_palette[17];
    struct drm_clip_rect damage_clip;
    spinlock_t damage_lock;
    struct work_struct damage_work;
    struct work_struct resume_work;
    struct mutex lock;
    bool delayed_hotplug;
    bool deferred_setup;
    int preferred_bpp;
  #ifdef CONFIG_FB_DEFERRED_IO;
    struct fb_deferred_io fbdefio;
  #endif;
};

like yes, it's a struct, but it's the struct 🫶

---

🧚 Members 🧚

• client — the DRM client that the generic fbdev emulation rolls with 💫
• buffer — the framebuffer the generic fbdev emulation is using, no cap
• fb — scanout framebuffer object, she's the main character of the actual screen 🌈
• dev — the DRM device, iykyk
• funcs — driver callbacks for the fb helper, so the driver gets to have opinions
• info — the emulated fbdev device info struct 🍓
• pseudo_palette — a fake palette of 16 colors. fake it till you make it 💅
• damage_clip — clip rectangle used with deferred_io to accumulate damage to the screen buffer
• damage_lock — spinlock protecting damage_clip. gotta keep her safe 🔒
• damage_work — worker used to flush the framebuffer
• resume_work — worker used during resume if the console lock is already taken
• lock — the top-level FBDEV helper lock. this protects all internal data structures and lists, such as connector_info and crtc_info.

FIXME: fbdev emulation locking is a mess and long term we want to protect all helper internal state with this lock as well as reduce core KMS locking as much as possible. 😭 (the kernel devs said it, not me)

• delayed_hotplug — a hotplug was received while fbdev wasn't in control of the DRM device, i.e. another KMS master was active. the output configuration needs to be reprobe when fbdev is in control again. she was on a break, ok 🙈
• deferred_setup — if no outputs are connected (disconnected or unknown) the FB helper code will defer setup until at least one of the outputs shows up. this field keeps track of the status so that setup can be retried at every hotplug event until it succeeds eventually. Resilient queen behavior 👑

Protected by lock.

• preferred_bpp — temporary storage for the driver's preferred BPP setting passed to FB helper initialization. this needs to be tracked so that deferred FB helper setup can pass this on.

See also: deferred_setup

• fbdefio — temporary storage for the driver's FB deferred I/O handler. if the driver uses the DRM fbdev emulation layer, this is set by the core to a generic deferred I/O handler if a driver is preferring to use a shadow buffer. shadow buffer era 🦋

---

💖 DESCRIPTION 💖

This is the main structure used by the fbdev helpers 🎀 drivers supporting fbdev emulation should embedded this into their overall driver structure. drivers must also fill out a struct drm_fb_helper_funcs with a few operations. like, a few, you got this 🫶

---

⭐ SEE ALSO ⭐

Kernel file ./include/drm/drm_fb_helper.h struct drm_fb_helper_surface_size(9), struct drm_fb_helper_funcs(9), DRM_FB_HELPER_DEFAULT_OPS(9)

---

okay that's the page bestie 💜 it lives in ./include/drm, it's the October 2026 edition of the Kernel API Manual, and the whole thing is filed under struct drm_fb_helper(9) — slay, go read it again, periodt 🔥👑