intel_dp_ms...eeds_modeset(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… intel_dp_mst_crtc_needs_modeset(9) πŸ’…

okay so bestie, welcome to the Kernel API Manual ✨ β€” yes this is a kernel API page, yes it's about DRM/i915, and yes you're gonna understand it. we're literally checking if a topology change means we gotta modeset a CRTC. iconic behavior tbh πŸŽ€


✨ NAME ✨

intel_dp_mst_crtc_needs_modeset β€” check if changes in topology need to modeset the given CRTC πŸ¦‹


🌸 SYNOPSIS 🌸

bool intel_dp_mst_crtc_needs_modeset (struct intel_atomic_state *state ,
struct intel_crtc *crtc );

πŸ’– ARGUMENTS πŸ’–

  • state β€” the atomic state, aka the whole vibe snapshot of what's going on rn 🫢
  • crtc β€” the CRTC you're checking for the modeset requirement, like "does this one need the glow-up"

πŸ‘‘ DESCRIPTION πŸ‘‘

So what this does: it checks if any change in an MST topology requires a forced modeset on crtc in this topology. highkey a vibe check for your display pipeline πŸ”₯

One such change β€” and this is the example the docs literally give β€” is enabling/disabling the DSC decompression state in the first branch device's UFP DPCD, as required by one CRTC, while the other crtc in the same topology is still active. In that situation you're gonna need a full modeset on crtc. no cap, that's the whole point πŸ’…

so yeah: topology changed, DSC decompression state in the first branch device's UFP DPCD flipped for one CRTC, other CRTC still active β†’ full modeset on crtc. periodt ✨


πŸ¦‹ SEE ALSO πŸ¦‹

Kernel file ./drivers/gpu/drm/i915/display/intel_dp_mst.c β€” the main character file 🌈


πŸ’€ ngl, this one's short but it's lowkey important β€” forced modesets are not a drill, bestie. don't skip the DSC decompression state check. πŸ™ˆ

and that's the whole page, bestie πŸ“ it lives in ./drivers/gpu/drm/i915/display, dated October 2026, from the Kernel API Manual β€” go forth and modeset responsibly πŸ§šπŸ’œ

πŸ“¦ where this page comes from