drm_atomic_..._plane_state(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’– NAME πŸ’–

drm_atomic_helper_check_plane_state β€” bestie, this is the vibe check for your plane state ✨

So like, you know how drm_atomic_..._plane_state(9) lives in the Kernel API Manual? Yeah. That's her. That's the page. POV: you're a DRM driver dev and you just want to know if your plane update is valid before you commit to it. Iconic. Let's go πŸŽ€


🌸 SYNOPSIS 🌸

int drm_atomic_helper_check_plane_state (struct drm_plane_state
*plane_state , const struct drm_crtc_state *crtc_state , int min_scale ,
int max_scale , bool can_position , bool can_update_disabled );

Not me dropping the whole signature like it's a fit pic πŸ“Έ β€” copy it exactly, no edits, iykyk.


πŸ¦‹ ARGUMENTS πŸ¦‹

  • plane_state β€” the plane state you're checking, aka the main character of this whole function πŸ’…
  • crtc_state β€” the CRTC state you're checking it against. Gotta make sure they're compatible, no cap.
  • min_scale β€” the minimum src:dest scaling factor, expressed in 16.16 fixed point. Yes bestie, fixed point, we love a bit-shifty queen πŸ”₯
  • max_scale β€” the maximum src:dest scaling factor, also in 16.16 fixed point. Respect the ceiling fr fr.
  • can_position β€” is it even legal to position the plane so it doesn't cover the entire CRTC? Like, is she allowed to be off to the side? This will generally only be false for primary planes πŸ‘€ (primary planes are the ones who have to cover the whole thing, sorry queen)
  • can_update_disabled β€” can the plane be updated while the CRTC is disabled? That's the question. That's the whole question πŸ™ˆ

✨ DESCRIPTION ✨

Okay so what does she actually do? She checks that a desired plane update is valid β€” a literal vibe check on your update before it hits the floor β€” and she also updates various bits of derived state for you. Clipped coordinates, etc. The little details. The garnish. πŸ“

Now here's the part for the drivers who like to do it themselves: even if you provide your own plane handling rather than using the helper-provided implementations, you may still wish to call this function. Why? To avoid duplication of error checking code, bestie. Don't rewrite the same checks by hand. That's not main character energy, that's just wasted effort. Reuse the helper. Slay. πŸ’œ


⭐ RETURN ⭐

  • Zero if the update appears valid 🫢
  • Error code on failure πŸ’€

That's it. Binary. She either eats or she doesn't.


🌈 SEE ALSO 🌈

Buckle up bestie, this list is LONG and we are NOT skipping a single one. Every single one of these is getting her moment πŸ‘‘

Like I said. LONG. But every single one showed up, because we don't do half-finished lists here 🧚


Heads up bestie: this page is literally just the check function β€” she validates and massages derived state, she doesn't commit anything. Don't go thinking the update already happened just because she returned 0. Look at the SEE ALSO crew for the commit-side stuff πŸ’…

Okay that's the page!! Sourced from ./drivers/gpu/drm, dated October 2026, and filed under the manual name drm_atomic_..._plane_state(9). Mwah πŸ’‹ Go validate those plane states, bestie β€” you're gonna eat 🫢✨

πŸ“¦ where this page comes from