drm_atomic_...t_for_fences(9)

📦 version 7.3.1, in nixpkgs unstable

💖 NAME 💖

okay so drm_atomic_helper_wait_for_fences — bestie, it literally waits for the fences stashed in the plane state. that's the whole vibe. no cap.

✨ SYNOPSIS ✨

int drm_atomic_helper_wait_for_fences (struct drm_device *dev , struct
       drm_atomic_commit *state , bool pre_swap );

🎀 ARGUMENTS 🎀

  • dev — the DRM device, aka the main character of this whole operation 🫶
  • state — the atomic state object, and it's holding the old state structures, lowkey carrying baggage
  • pre_swap — if it's true, you get an interruptible wait and state is the new state. otherwise, state is the old state. pick a lane, bestie 💅

🌸 DESCRIPTION 🌸

so for implicit sync, the driver should fish the exclusive fence out from the incoming fb's and stash it in the drm_plane_state. iconic behaviour, honestly. this here gets called after drm_atomic_helper_swap_state, so it uses the current plane state — and it just uses the atomic state to find the changed planes. that's it, that's the job ✨

now, pre_swap exists because the point where we block for fences moves around depending on whether an atomic commit is blocking or non-blocking. it's giving "depends on the situation" energy:

  • for a non-blocking commit, all the waiting needs to happen after drm_atomic_helper_swap_state is called
  • for blocking commits, we wanna wait before we do anything that can't be easily rolled back — that is, before we call drm_atomic_helper_swap_state 😭
fr fr, order matters here. don't come for me if you get it backwards.

Returns zero if success, or < 0 if dma_fence_wait fails. slay when it's zero, sad butterfly when it's not 🦋

🧚 SEE ALSO 🧚

like, this function has so many friends, i'm obsessed. go read these next:

k byeee 🫶 this page lives in ./drivers/gpu/drm, it's from October 2026, and yes — it's the drm_atomic_...t_for_fences(9) page, Kernel API Manual edition. go wait for your fences, bestie, you got this 💜

📦 where this page comes from