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

Kevin Brace kevinbrace at gmx.com
Mon Nov 2 23:50:43 UTC 2020


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



More information about the dri-devel mailing list