STRUCT DRM_FRAMEBUFFER_FUNCS(9)

✨ NAME ✨

struct drm_framebuffer_funcs — framebuffer hooks 🎀

okay so this page is straight out of the Kernel API Manual, and it's literally the lil' bundle of hook functions that the DRM core calls into when it needs your driver to do framebuffer stuff. bestie. it's giving "callback central" and we're obsessed 💅

🌸 SYNOPSIS 🌸

struct drm_framebuffer_funcs {
    void (*destroy)(struct drm_framebuffer *framebuffer);
    int (*create_handle)(struct drm_framebuffer *fb, struct drm_file *file_priv, unsigned int *handle);
    int (*dirty)(struct drm_framebuffer *framebuffer, struct drm_file *file_priv, unsigned flags, unsigned color, struct drm_clip_rect *clips, unsigned num_clips);
 };

like, that's the whole struct. three little function pointers carrying the entire vibe 🔥

🧚 Members 🧚

• destroy — the cleanup girlie 💖 she frees your framebuffer resources, and specifically also unreferences the backing storage. The core guarantees it'll call this for every framebuffer that was successfully created by calling drm_mode_config_funcs.fb_create. And heads up: drivers must also call drm_framebuffer_cleanup to release the DRM core resources for this framebuffer. two steps, no skipping 🫶
• create_handle — makes a buffer handle in the driver-specific buffer manager (either GEM or TTM), valid for the passed-in struct drm_file. The core uses this to implement the GETFB IOCTL, which returns — for sufficiently privileged user — also a native buffer handle. why do we care? because it lets modesetting clients transition seamlessly: copy the current screen contents to a private buffer and blend between that and the new contents. iconic behavior fr fr ✨
  • GEM based drivers should call drm_gem_handle_create to create the handle. that's the move, no cap.
  • RETURNS: 0 on success or a negative error code on failure. 😭
• dirty — optional callback for the dirty fb IOCTL. 👀 Userspace can ping the driver through this callback to say "hey, an area of the framebuffer changed, please flush it to the display hardware." It can also be used internally, e.g. by the fbdev emulation — though that's not the case currently. 🙈
  • See the documentation in drm_mode.h for the struct drm_mode_fb_dirty_cmd for more info, because all the semantics and arguments have a one to one mapping on this function. like, one to one, literally 💀
  • Atomic drivers should use drm_atomic_helper_dirtyfb to implement this hook. periodt.
  • RETURNS: 0 on success or a negative error code on failure. same energy, no surprises 💜

🦋 SEE ALSO 🦋

Kernel file ./include/drm/drm_framebuffer.h — go read it, iykyk:

• struct drm_framebuffer(9)
• drm_framebuffer_get(9)
• drm_framebuffer_put(9)
• drm_framebuffer_read_refcount(9)
• drm_framebuffer_assign(9)
• struct drm_afbc_framebuffer(9)

ok that's the whole page bestie, go forth and implement your hooks responsibly 💖✨

and that's a wrap, mwah 💋 — this one lives in ./include/drm, dated October 2026, and yes she's still signing off as struct drm_f...buffer_funcs(9) because the terminal column width said so 🎀