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@xxxxxxxxxxxxxxx> > To: "Kevin Brace" <kevinbrace@xxxxxxx> > Cc: "dri-devel" <dri-devel@xxxxxxxxxxxxxxxxxxxxx> > 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 > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
