drm_framebuffer_lookup(9)

📦 version 7.3.1, in nixpkgs unstable

💖 drm_framebuffer_lookup(9) 💖

okay so first things first — bestie, you're reading the Kernel API Manual page for drm_framebuffer_lookup, and honestly? it's a short one but she matters. let's get into it 🫶

✨ NAME ✨

drm_framebuffer_lookup — the girlies call it "look up a drm framebuffer and grab a reference" and that's literally what it does, no cap 💅

🌸 SYNOPSIS 🌸

struct drm_framebuffer * drm_framebuffer_lookup (struct drm_device *dev
, struct drm_file *file_priv , uint32_t id );

like... that's her signature. that's the whole vibe. copy it exactly, don't @ me 😌

🎀 ARGUMENTS 🎀

  • dev — the drm device, the main character of this whole operation 👑
  • file_priv — the drm file we're checking for a lease against. yes, against. it's giving background check energy 🔍
  • id — the id of the fb object. the fb in question. the one we're looking up 🎯

💜 DESCRIPTION 💜

so here's the tea ☕ — if this call succeeds, it grabs an additional reference to the framebuffer. like, it takes hold of it and goes "mine now, kinda" 🙈

and because of that, callers need to make sure they eventually unreference the returned framebuffer again, using drm_framebuffer_put. this is not optional, bestie, this is the whole deal — you took a reference, you give it back 🫶

⚠️ fr fr: don't forget the drm_framebuffer_put. leaking a reference is not the slay you think it is. it's giving memory leak 💀

🦋 SEE ALSO 🦋

the whole friend group, assembled 🌈:

and that's the page, gorgeous ✨ this lil number lives in ./drivers/gpu/drm, dated October 2026, and she's filed under drm_framebuffer_lookup(9). go forth and put your references back where they belong 💖🎀🧚

📦 where this page comes from