Hi, > Hmm, I don't like that interface. Can you cite examples of other > ioctls that behave this way? It doesn't feel like an elegant user > interface; the user can get the dmabuf, but only after they query the > dmabuf, even though the get-dmabuf ioctl returns the same data as the > query-plane ioctl, but they can't get the dmabuf if the plane has > changed in the interim, which is not something the user can > know. Are > we causing our own problems with this model of cycling through dmabuf > fds? We talked previously about an enum of plane types, primary and > cursor. What if the user was simply able to get a dmabuf fd for each > of > those and they queried the current plane information via those fds? > IOW, the fd is persistent and specific to a given plane type, but the > format within it is dynamic. Will not work due to how dma-bufs are designed. But, yes, the QUERY then GET split is ugly for a number of reasons. Does gvt track the live cycle of all dma-bufs it has handed out? If so, then maybe we can let the kernel check whenever a dma-buf for the current plane exists? And if that isn't the case hand out a dma- buf right away, without expecting userspace explicitly asking for it? That will simplify the interface and remove the race condition at the expense of some additional bookkeeping in the kernel. cheers, Gerd _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
