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 at gmail.com> ?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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.linuxfoundation.org/pipermail/virtualization/attachments/20210626/d4bc0f96/attachment-0001.html>