Why is atomic_disable callback's plane->state->crtc sometimes null?

[Ville Syrjälä]

On Tue, Nov 03, 2020 at 12:50:43AM +0100, Kevin Brace wrote:
> Hi,
> 
> First, I will like to thank those who gave me hints on how to proceed with getting rid of an unwanted double allocation of visible portion of the frame buffer.
> 
> https://lists.freedesktop.org/archives/dri-devel/2020-October/283452.html
> 
> I may repost the question later to the mailing list based on the feedback I received.
>     After a few more days of trying, I finally got my prototype OpenChrome DRM atomic modesetting code barely working for both primary and cursor planes (cursor plane was not working previously).
> I finally figured out what was causing the freeze, and in fact, I am writing this e-mail from the very computer that has the experimental code running.
> The code itself is still quite unstable that standby resume is not working and VT (Virtual Terminal) is broken, but X Server is working fine just with a few minor weird artifact lines on the right and bottom edges of the screen.
> Anyway, the question I have here (and I am assuming that Daniel Vetter will give me an explanation) is that I noticed that for cursor plane's atomic_disable callback, plane->state->crtc is null or sometimes null.
> Why is this?

It can be NULL if the user set it to NULL. That's how you disable
a plane: crtc=NULL + fb=NULL.

Also you shouldn't really use plane->state directly anymore.
Instead you should rather use for_each_{new,old,oldnew}_plane_in_state()
and/or drm_atomic_get_{new,old}_plane_state().

-- 
Ville Syrjälä
Intel