Some additional detail-- the parent process is a UI layer using WPEWebKit rendering via EGL+drmModeAtomicCommit. For media playback, it fork+execs a child process and passes its open libdrm file descriptor. The child media player process displays its own media playback plane and OSD UI plane. If the player terminates abnormally, those planes remain visible. When the WPEWebKit renders its next frame, it remains obscured "under" the now orphaned media player planes. Worked around the issue by making the media player fork and then wait for itself to terminate allow reliable cleanup regardless of how the player terminated.
Since the orphaned framebuffer was allocated via "/dev/dma_heap/system" by the now terminated media player, had assumed that memory could be inadvertantly reallocated. However, running memory stress tests never changed the display. Does calling DRM_IOCTL_PRIME_FD_TO_HANDLE with the shared libdrm file descriptor mean the framebuffer lifespan is partially tied to the libdrm file descriptor lifespan (when shared between multiple processes)?
Since the orphaned framebuffer was allocated via "/dev/dma_heap/system" by the now terminated media player, had assumed that memory could be inadvertantly reallocated. However, running memory stress tests never changed the display. Does calling DRM_IOCTL_PRIME_FD_TO_HANDLE with the shared libdrm file descriptor mean the framebuffer lifespan is partially tied to the libdrm file descriptor lifespan (when shared between multiple processes)?
Statistics: Posted by Vraz — Thu Dec 26, 2024 9:53 pm