drm_atomic_...licate_state(9)

📦 version 7.3.1, in nixpkgs unstable

💅 drm_atomic_helper_duplicate_state — a whole <italic>Kernel API Manual</italic> moment ✨

okay bestie, so this one is drm_atomic_helper_duplicate_state(9) and it's literally the "save a copy before you do something drastic" girlie of the DRM atomic world 🎀

✨ SYNOPSIS ✨

struct drm_atomic_commit * drm_atomic_helper_duplicate_state (struct
drm_device *dev , struct drm_modeset_acquire_ctx *ctx );

🌸 ARGUMENTS 🌸

  • dev — the DRM device, obvi 💖
  • ctx — the lock acquisition context. that's the vibe check for your locks 🔒

🦋 DESCRIPTION 🦋

okay so what this does 💅 — it makes a copy of the current atomic state by looping over literally all the objects and duplicating their respective states. no cap, every single one. this is used, for example, by the suspend/resume support code to save the state prior to suspend so that it can be restored upon resume. iconic behavior honestly 🫶

⚠️ note: this treats atomic state as persistent between save and restore. drivers must make sure that this is actually possible and won't result in confusion or erroneous behaviour. like, don't just assume, bestie — check 😭
⚠️ also note: if callers haven't already acquired all modeset locks, this might return -EDEADLK, which must be handled by calling drm_modeset_backoff. so don't ignore that return value, or it's giving deadlock 💀

see also: drm_atomic_helper_suspend, drm_atomic_helper_resume ✨

👑 RETURN 👑

A pointer to the copy of the atomic state object on success, or an ERR_PTR-encoded error code on failure. so like, always check it, fr fr 🌈

💜 SEE ALSO 💜

like, that's the whole friend group right there 😭💖

okay that's the whole page bestie, you ate that 🫶 this little ✨ bop ✨ comes to you from ./drivers/gpu/drm, dated October 2026 — and it's filed right back under drm_atomic_...licate_state(9), periodt 💅🎀

📦 where this page comes from