for the 2nd point, I begin to understand the logic,
there are some userspace priv data passed with sgtable between guest and host os; width/height/stride/format and other information can be sent inside these private data.
these private data is opaque to kernel driver, doesn't require negotiation from the point of dmabuf.
Halley Zhao <aihua.halley.zhao@xxxxxxxxx> 于2021年6月23日周三 下午8:47写道：
Hi Experts:I notice that dmabuf sharing has been supported early this year: https://lists.linuxfoundation.org/pipermail/virtualization/2021-February/052708.htmlI'd like use it, but have some other thoughts, seeking your advice:1. How about use shared dmabuf stream as virtual camera on host os side?the above implementation supports qemu for now, with newly defined ioctl command and events; but not available for common app usage. if we add dmabuf stream as a node for V4L2, then app can use the stream as a virtual camera.though, there is still some gap in V4L2, since V4L2 support V4L2_MEMORY_DMABUF by importing external dmabuf. anyway, I can give it a quick try: app may send dmabuf to V4L2 and host kernel driver copy the guest dmabuf data to app created dmabuf.2. in the above implementation, dmabuf is shared between guest and host with few information, size only. w/o width/height/stride/format information. I don't know how the userspace app could retrieve these buffer attributes. the patch creates some special ioctl command and data structure for new usage.as to guest and host kernel driver, how about reuse fb or v4l2(OUTPUT) device command for the shared dmabuf? then we can reuse the well-defined interface of fb or v4l2.appreciate for your comments.
_______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
