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
