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

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

[Kevin Brace]

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?
Assuming that plane->state->crtc will not be null was one the reason why the code was not working, so I will like to know the reason.

Regards,

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

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

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

[Kevin Brace]

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@linux.intel.com>
> To: "Kevin Brace" <kevinbrace@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