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

Kevin Brace kevinbrace at gmx.com
Wed Nov 11 18:06:00 UTC 2020


Hi Ville,

I was able to find a satisfactory workaround.
What I was trying to do is to get a pointer to "struct drm_device" via crtc pointer.
I switched to getting it from "struct drm_plane".
On a separate note, I will look into using drm_atomic_get_new_plane_state() and drm_atomic_get_old_plane_state() in my code soon.

Regards,

Kevin Brace
Brace Computer Labortory blog
https://bracecomputerlab.com


> Sent: Monday, November 09, 2020 at 9:26 AM
> From: "Ville Syrjälä" <ville.syrjala at linux.intel.com>
> To: "Kevin Brace" <kevinbrace at gmx.com>
> Cc: "dri-devel" <dri-devel at lists.freedesktop.org>
> Subject: Re: Why is atomic_disable callback's plane->state->crtc sometimes null?
>
> 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
>


More information about the dri-devel mailing list