Hi all,
Benjamin Gaignard's 'DELETE_BUFS' series [1] is almost ready, but there is
one outstanding issue: it works closely together with VIDIOC_CREATE_BUFS,
but that ioctl has long since been a thorn in my eye due to the use of
struct v4l2_format embedded in the struct v4l2_create_buffers. This makes
it hard to use in applications.
The only fields of that struct v4l2_format that are actually used are:
type
and, depending on 'type':
pix.sizeimage
pix_mp.num_planes, pix_mp.plane_fmt.sizeimage
sdr.buffersize
meta.buffersize
vbi.samples_per_line, vbi.count
sliced.io_size
See vb2_create_bufs() in videobuf2-v4l2.c.
It's a pain to use since you need to fill in different fields
depending on the type in order to allocate the new buffer memory,
but all you want is just to give new buffer sizes.
I propose to add a new ioctl:
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 03443833aaaa..a7398e4c85e7 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2624,6 +2624,39 @@ struct v4l2_create_buffers {
__u32 reserved[5];
};
+/**
+ * struct v4l2_add_buffers - VIDIOC_ADD_BUFS argument
+ * @type: enum v4l2_buf_type
+ * @memory: enum v4l2_memory; buffer memory type
+ * @count: entry: number of requested buffers,
+ * return: number of created buffers
+ * @num_planes: requested number of planes for each buffer
+ * @sizes: requested plane sizes for each buffer
+ * @start_index:on return, index of the first created buffer
+ * @total_count:on return, the total number of allocated buffers
+ * @capabilities: capabilities of this buffer type.
+ * @flags: additional buffer management attributes (ignored unless the
+ * queue has V4L2_BUF_CAP_SUPPORTS_MMAP_CACHE_HINTS capability
+ * and configured for MMAP streaming I/O).
+ * @max_num_buffers: if V4L2_BUF_CAP_SUPPORTS_MAX_NUM_BUFFERS capability flag is set
+ * this field indicate the maximum possible number of buffers
+ * for this queue.
+ * @reserved: future extensions
+ */
+struct v4l2_add_buffers {
+ __u32 type;
+ __u32 memory;
+ __u32 count;
+ __u32 num_planes;
+ __u32 size[VIDEO_MAX_PLANES];
+ __u32 start_index;
+ __u32 total_count;
+ __u32 capabilities;
+ __u32 flags;
+ __u32 max_num_buffers;
+ __u32 reserved[7];
+};
+
/**
* struct v4l2_delete_buffers - VIDIOC_DELETE_BUFS argument
* @index: the first buffer to be deleted
@@ -2738,6 +2771,7 @@ struct v4l2_delete_buffers {
#define VIDIOC_QUERY_EXT_CTRL _IOWR('V', 103, struct v4l2_query_ext_ctrl)
#define VIDIOC_DELETE_BUFS _IOWR('V', 104, struct v4l2_delete_buffers)
+#define VIDIOC_ADD_BUFS _IOWR('V', 105, struct v4l2_add_buffers)
/* Reminder: when adding new ioctls please add support for them to
Note that this patch sits on top of [1].
The new struct is mostly the same as v4l2_create_buffers, but replacing the
embedded v4l2_format with just the data it actually needs. I also renamed
'index' to 'start_index' and added a new 'total_count' field to report the
total number of buffers. VIDIOC_CREATE_BUFS used the 'index' field for that
when called with count == 0, but that is awkward once you allow for deleting
buffers.
Implementing VIDIOC_ADD_BUFS would be very easy, it is almost all done in
vb2. Drivers would just need to point .vidioc_add_bufs to vb2_ioctl_add_bufs.
The vb2_queue ops do not change since those are already based on just an
array of requested sizes.
One reason I am bringing this up is that this has a potential impact on the
name of the new ioctl in [1]. Do we call it 'VIDIOC_DELETE_BUFS' or
'VIDIOC_REMOVE_BUFS'?
I like the ADD/REMOVE pair better than ADD/DELETE. I never quite liked
'CREATE/DELETE' since buffer memory is only created/deleted in the MMAP
streaming case, not with DMABUF/USERPTR. I think add/remove are better names.
I think CREATE/REMOVE is also acceptable, so I am leaning towards calling
the new ioctl in [1] VIDIOC_REMOVE_BUFS instead of VIDIOC_DELETE_BUFS.
So, please comment on this RFC, both whether adding a CREATE_BUFS replacement
makes sense, and whether using REMOVE_BUFS instead of DELETE_BUFS makes sense.
Ideally it would be nice to introduce both ADD_BUFS and REMOVE_BUFS at the
same time, so any userspace application that needs to use REMOVE_BUFS to
remove buffers can rely on the new ADD_BUFS ioctl being available as well.
Regards,
Hans
[1]: https://patchwork.linuxtv.org/project/linux-media/list/?series=12195
