Hi Hans, On Fri, Aug 24, 2018 at 5:22 PM Hans Verkuil <hverk...@xs4all.nl> wrote: > > From: Hans Verkuil <hansv...@cisco.com> > > VIDIOC_REQBUFS and VIDIOC_CREATE_BUFFERS will return capabilities > telling userspace what the given buffer type is capable of. >
Please see my comments below. > Signed-off-by: Hans Verkuil <hansv...@cisco.com> > --- > .../media/uapi/v4l/vidioc-create-bufs.rst | 10 +++++- > .../media/uapi/v4l/vidioc-reqbufs.rst | 36 ++++++++++++++++++- > include/uapi/linux/videodev2.h | 13 +++++-- > 3 files changed, 55 insertions(+), 4 deletions(-) > > diff --git a/Documentation/media/uapi/v4l/vidioc-create-bufs.rst > b/Documentation/media/uapi/v4l/vidioc-create-bufs.rst > index a39e18d69511..fd34d3f236c9 100644 > --- a/Documentation/media/uapi/v4l/vidioc-create-bufs.rst > +++ b/Documentation/media/uapi/v4l/vidioc-create-bufs.rst > @@ -102,7 +102,15 @@ than the number requested. > - ``format`` > - Filled in by the application, preserved by the driver. > * - __u32 > - - ``reserved``\ [8] > + - ``capabilities`` > + - Set by the driver. If 0, then the driver doesn't support > + capabilities. In that case all you know is that the driver is > + guaranteed to support ``V4L2_MEMORY_MMAP`` and *might* support > + other :c:type:`v4l2_memory` types. It will not support any others > + capabilities. See :ref:`here <v4l2-buf-capabilities>` for a list of > the > + capabilities. Perhaps it would make sense to document how the application is expected to query for these capabilities? Right now, the application is expected to fill in the "memory" field in this struct (and reqbufs counterpart), but it sounds a bit strange that one needs to know what "memory" value to write there to query what set of "memory" values is supported. In theory, MMAP is expected to be always supported, but it sounds strange anyway. Also, is there a way to call REQBUFS without altering the buffer allocation? Best regards, Tomasz
