15:13 <cmeissl[m]> tomeu: yes, or at least kind of. afaict after digging though the code in mesa it looks like the client would have to use the display node with kmsro to receive a scanout able dma buffer in the compositor. otherwise private memory would be allocated. But the wayland egl platform disables use of dmabuf feedback when I send card1 because it is not a render node. Sending the render node from etnaviv enables the use of dmabuf feedback, but

15:13 <cmeissl[m]> kms->ro will be NULL.

15:14 <cmeissl[m]> I opened https://gitlab.freedesktop.org/mesa/mesa/-/issues/8384 and asked in dri-devel, where I received some feedback about the problem. The last response from daniels suggests that it would be better to announce the render node as the main device and make the wayland platform code properly react on the scanout tranche target device.

16:00 <cmeissl[m]> tomeu: In the mean time I just patched the platform to allow card1 to be used as the main device. This allows my compositor to use the client buffer for scan-out on both, the overlay and the primary plane. So at least I now know it technically should work.

16:08 <cmeissl[m]> But I saw something else today that I need to take a closer look. I am trying to use the 2D Core for composition and implemented some minimal example using the tests and examples from etnaviv to send commands to the gpu. At some point after running the example a few times it fails to allocate memory. I need to confirm, but it looks like allocating a gbm bo with SCANOUT and afterwards mapping it somehow leaks it. The map is unmapped and the

16:08 <cmeissl[m]> bo is also cleaned up, but there is still a dmabuf active after exit. The dmabuf is attached to etnaviv.

16:29 <cmeissl[m]> maybe, it seems that calling gbm_bo_map creates it internally

16:32 <cmeissl[m]> is it possible it references itself and therefore it doesn't get cleaned up when calling gbm_bo_destroy?