Re: [PATCH 4/5] videodev2.h: add new capabilities for buffer types

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Regards,

	Hans



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux