On 08/29/2018 10:49 AM, Tomasz Figa wrote: > On Tue, Aug 28, 2018 at 9:37 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >> >> On 24/08/18 16:36, Tomasz Figa wrote: >>> Hi Hans, >>> >>> On Fri, Aug 24, 2018 at 5:22 PM Hans Verkuil <hverkuil@xxxxxxxxx> wrote: >>>> >>>> From: Hans Verkuil <hansverk@xxxxxxxxx> >>>> >>>> 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 <hansverk@xxxxxxxxx> >>>> --- >>>> .../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? >> >> No, this is only possible with CREATE_BUFS. >> >> But it is reasonable to call REQBUFS with a count of 0, since you want to >> start with a clean slate anyway. >> >> The only option I see would be to introduce a new memory type (e.g. >> V4L2_MEMORY_CAPS) to just return the capabilities. But that's more ugly >> then just requiring that you use MMAP when calling this. >> >> I'm inclined to just document that you need to set memory to MMAP if >> you want to get the capabilities since MMAP is always guaranteed to >> exist. > > I guess it's the least evil we can get without changing the API too > much. Fair enough. > Can you ack the updated patch: https://www.mail-archive.com/linux-media@xxxxxxxxxxxxxxx/msg134624.html And take a look at patches 6-10 as well, if you have time. I'd like to get this merged in a request topic branch asap. Regards, Hans > Best regards, > Tomasz >
