Issues with dmabuf use in dbus interface

Here is a discussion I recently had with Bilal about the dbus interface between libmks and qemu:

me> I am looking at the dbus interface definition in libmks - should there be some kind of buffer pool thing ?
    I would expect to receive a dmabuf from qemu and return it at some point when it is no longer in use
bilal> what do you mean by no longer in use here?
me> we get a dmabuf, and we pass it on to mutter, which either reads it to composite it into its framebuffer,
    or sets up direct scanout from it. And until that is done, we kinda need exclusive access to the dmabuf,
    so its contents don't change underneath us
    typically, you have a pool of buffers that gets set up between the producer and the consumer, and the
    individual buffers for each frame get taken from that pool by the producer and re-added to it after the
    consumer is done with it
bilal> right i see, currently per my understanding, virtio-gpu already do something similar to what you
       describe but the dbus interface doesn't provide a way a method to call when you are done with a scanout
me> that is probably something that needs fixing
bilal> the problem is ScanoutDMABUF is called and then followed or not by one or multiple UpdateDMABUF calls
       so we can't tell if we are done with the scanout or not, from libmks side
       elmarco would know best for sure
       actually i think that is the reason why i can't close the fd on the release callback of the dmabuf
       texture per your suggestion last time
       but i didn't had the time to dig further

@marcandre.lureau do you have any insights on this?