STRUCT DRM_FRAMEBUFFER(9)
π struct drm_framebuffer(9) π
okay so bestie, welcome to the Kernel API Manual β this is the page for struct drm_framebuffer(9), aka the frame buffer object that lowkey runs the whole modesetting vibe β¨. itβs giving βI hold pixels, refcounts, and main-character energy,β and honestly? iconic.
πΈ NAME πΈ
struct drm_framebuffer β frame buffer object π
β¨ SYNOPSIS β¨
struct drm_framebuffer {
struct drm_device *dev;
struct list_head head;
struct drm_mode_object base;
char comm[TASK_COMM_LEN];
const struct drm_format_info *format;
const struct drm_framebuffer_funcs *funcs;
unsigned int pitches[DRM_FORMAT_MAX_PLANES];
unsigned int offsets[DRM_FORMAT_MAX_PLANES];
uint64_t modifier;
unsigned int width;
unsigned int height;
int flags;
unsigned int internal_flags;
struct list_head filp_head;
struct drm_gem_object *obj[DRM_FORMAT_MAX_PLANES];
};
π Members π
devβ the DRM device this framebuffer belongs to. home base πheadβ sits ondrm_mode_config.fb_list, and access is protected bydrm_mode_config.fb_lock. πbaseβ the base modeset object structure, and it contains the reference count. thatβs where the refcount lives, periodt πcommβ the name of the process allocating the fb; itβs used for fb dumping. π«Άformatβ framebuffer format information. slay πfuncsβ the framebuffer vfunc table. πpitchesβ line stride per buffer. for a userspace-created object, this is copied fromdrm_mode_fb_cmd2. β¨offsetsβ offset from buffer start to the actual pixel data, in bytes, per buffer. for a userspace-created object, this is copied fromdrm_mode_fb_cmd2. π«
okay bestie, listen: this is a linear offset, and it does not take tiling or buffer layout per modifier into account. itβs meant to be used when the actual pixel data for this framebuffer plane starts at an offset, e.g. when multiple planes are allocated within the same backing storage buffer object. for tiled layouts this generally means its offsets must at least be tile-size aligned, but hardware often has stricter requirements. π and do not use this to specify x/y pixel offsets into the buffer data (even for linear buffers). specifying an x/y pixel offset is instead done through the source rectangle in struct drm_plane_state. no cap.
modifierβ data layout modifier. this describes tiling, or also special layouts (like compression) of auxiliary buffers. for a userspace-created object, this is copied fromdrm_mode_fb_cmd2. πwidthβ logical width of the visible area of the framebuffer, in pixels. πheightβ logical height of the visible area of the framebuffer, in pixels. πflagsβ framebuffer flags likeDRM_MODE_FB_INTERLACEDorDRM_MODE_FB_MODIFIERS. π©internal_flagsβ framebuffer flags likeDRM_FRAMEBUFFER_HAS_HANDLE_REF. π₯filp_headβ placed ondrm_file.fbs, protected bydrm_file.fbs_lock. πobjβ GEM objects backing the framebuffer, one per plane (optional). this is used by the GEM framebuffer helpers, see e.g.drm_gem_fb_create. π§
πΈ Description πΈ
so the fb is refcounted for the benefit of driver internals β for example, some hardware disables a CRTC/plane asynchronously, and scanout does not actually complete until the next vblank. so some cleanup (like releasing the reference(s) on the backing GEM bo(s)) should be deferred. in cases like this, the driver would like to hold a ref to the fb even though it has already been removed from userspace perspective. see drm_framebuffer_get and drm_framebuffer_put. π«Ά
the refcount is stored inside the mode object base. and thatβs the tea π
π¦ SEE ALSO π¦
Kernel file ./include/drm/drm_framebuffer.h structdrm_framebuffer_funcs(9)drm_framebuffer_get(9)drm_framebuffer_put(9)drm_framebuffer_read_refcount(9)drm_framebuffer_assign(9)struct drm_afbc_framebuffer(9)
source/version: ./include/drm β’ date: October 2026 β’ page: struct drm_framebuffer(9) in the Kernel API Manual β mwah πβ¨
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms