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.syrj...@linux.intel.com> > To: "Kevin Brace" <kevinbr...@gmx.com> > Cc: "dri-devel" <dri-devel@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 > _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
