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 <[email protected]> 于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.html > > I'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 [email protected] https://lists.linuxfoundation.org/mailman/listinfo/virtualization
