Em 23-01-2012 14:42, Mauro Carvalho Chehab escreveu:
> Em 23-01-2012 13:56, Tomasz Stanislawski escreveu:
>> Hi Mauro,
>>
>> On 01/23/2012 04:04 PM, Mauro Carvalho Chehab wrote:
>>> Em 23-01-2012 12:42, Tomasz Stanislawski escreveu:
Hi Mauro.
On 01/23/2012 03:32 PM, Mauro Carvalho Chehab wrote:
> Em 23-01-2012 11:51, Tomasz Stanislawski escreveu:
>> This patch adds extension to V4L2 api. It allow to export a mmap buffer
>> as file
>> descriptor. New ioctl VIDIOC_EXPBUF is added. It takes a buffer offset
>> used by
>> mmap and return a file descriptor on success.
>
> This requires more discussions.
>
> The usecase for this new API seems to replace the features previously
> provided
> by the overlay mode. There, not only the buffer were exposed to
> userspace, but
> some control were provided, in order to control the overlay window.
This ioctl was introduced to support exporting of V4L2 buffers via dma-buf
interface. This framework was little common with overlay mode. Could you
describe what overlay mode feature is replaced by VIDIOC_EXPBUF?
>>>
>>> The V4L2 API doesn't just export "raw" buffers. It provides a logic to
>>> control
>>> the streams, with includes buffer settings, buffer queue/dequeue, buffer
>>> meta-data
>>> (like timestamps), etc.
>>
>> The DMABUF buffers are handled by vb2-core. It provides control for queuing
>> and passing streaming and metadata management (like timestamps) to the
>> driver.
>>
>>>
>>> I would expect to see something similar for the dma buffers.
>>
>> Those features may be introduced to dma-buf. As I understand queue/dequeue
>> refers to passing
>> ownership between a CPU and a driver. It is handled in vb2-core. Passing
>> buffer between multiple
>> APIs like V4L2 and DRM will be probably handled in the userspace. Currently
>> the dma-buf provides
>> only the mechanism for mapping the same memory by multiple devices.
>
> I'm not sure if the dma-buf itself should have such meta data, but the V4L2
> API
> likely needs it.
>
>>>
>>> With regards to the overlay mode, this is the old way to export DMA buffers
>>> between
>>> a video capture driver and a graphics adapter driver. A dma-buf interface
>>> will
>>> superseed the video overlay mode, as it will provide more features. Yet,
>>> care
>>> should be taken when writing the userspace interface, in order to be sure
>>> that all
>>> features needed will be provided there.
>>>
>>
>> The s5p-tv and s5p-fimc do not have support for OVERLAY mode. As I know
>> vb2-core
>> has no support for the mode, either.
>
> True. It was decided that overlay is an old design, and a dma-buffer
> oriented approach would be needed. So, the decision were to not implement
> anything there, until a proper dma-buf support were not added.
>
>> What kind of features present in OVERLAYS are
>> needed in dmabuf? Note that dmabuf do not have be used only for buffers with
>> video data.
>
> That's a good point. Basically, Ovelay mode is supported by
> those 3 ioctl's:
>
> #define VIDIOC_G_FBUF_IOR('V', 10, struct v4l2_framebuffer)
> #define VIDIOC_S_FBUF_IOW('V', 11, struct v4l2_framebuffer)
> #define VIDIOC_OVERLAY _IOW('V', 14, int)
>
> With use these structs:
>
> struct v4l2_pix_format {
> __u32 width;
> __u32 height;
> __u32 pixelformat;
> enum v4l2_field field;
> __u32 bytesperline;
> __u32 sizeimage;
> enum v4l2_colorspacecolorspace;
> __u32 priv;
> };
>
> struct v4l2_framebuffer {
> __u32 capability;
> __u32 flags;
>
> void*base;/* Should be replaced
> by the DMA buf specifics */
> struct v4l2_pix_format fmt;
> };
> /* Flags for the 'capability' field. Read only */
> #define V4L2_FBUF_CAP_EXTERNOVERLAY 0x0001
> #define V4L2_FBUF_CAP_CHROMAKEY 0x0002
> #define V4L2_FBUF_CAP_LIST_CLIPPING 0x0004
> #define V4L2_FBUF_CAP_BITMAP_CLIPPING 0x0008
> #define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
> #define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
> #define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
> #define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
> /* Flags for the 'flags' field. */
> #define V4L2_FBUF_FLAG_PRIMARY 0x0001
> #define V4L2_FBUF_FLAG_OVERLAY 0x0002
> #define V4L2_FBUF_FLAG_CHROMAKEY0x0004
> #define V4L2_FBUF_FLAG_LOCAL_ALPHA0x0008
> #define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
> #define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
> #define V4L2_FBUF_FLAG_SRC_CHROMAKEY0x0040
>
> It should be noticed that devices that support OVERLAY can provide
> data on both dma-buffer sharing and via the standard MMAP/read() mode at
> the same time, each with a different v
