Hello All
This RFC will address the problem that some ioctl() commands would be
called many times until that command got all the all its entries. Those
ioctl() command are:
- VIDIOC_ENUM_FMT
- VIDIOC_QUERYCTRL
- VIDIOC_ENUMSTD and VIDIOC_SUBDEV_ENUMSTD
Generally speaking, all enumeration type commands would lead to
frequently context switch between userspace and kernel space. A few
enumeration commands listed below may not meet this problem in some
cases, as they could present their entries in a step wise way.
- VIDIOC_ENUM_FRAMESIZES
- VIDIOC_ENUM_FRAMEINTERVALS
A simple solution that we could bring and improve from DRM is the blob
object(struct drm_property_blob).
We could extend the existing ioctl() in this way:
1. VIDIOC_ENUM_EXT_FMT would turn a blob id and the memory size
requirement that usespace should prepare
for storing.
2. Appication call VIDIOC_GETPROPBLOB with blob id and a userspace
pointer which should be enough for storing.
3. V4L2 framework fill the that userptr with context likes this:
struct v4l2_blob_prop {
__u32 version;
__u32 payload_size;
__u32 payload[];
};
4. The parsing of payload would depend on its version which
v4l2_blob_prop.version says, and each entry in the payload could be
variable length, likes this:
struct v4l2_ext_pix_mod_desc {
__u64 modifier;
__u64 allocate_hints; /* heap flags shard by DMA-heap */
__u32 num_of_planes;
__u32 plane_sizes[8];
__u32 colorimetry_flags;
};
struct v4l2_ext_pix_desc {
__u32 fourcc;
__u32 num_of_modifies;
struct v4l2_ext_pix_mod_desc[];
};
In this design, we could avoid the problem that we could hardly extend
our uAPI for V4L2, all the structure must be a fixed size.
Here are some options design that people want for this RFC:
1. Do we need to call the ioctl() command itself(likes
VIDIOC_ENUM_EXT_FMT) which let the driver to flush its internal property
cache or calling VIDIOC_GETPROPBLOB is enough?
2. Should we make MC node support this feature only or standard video
node could? A thought from pinchartl is that every driver should have a
MC node even for the stateful driver.
The implementation of RFC could be a foundation for ext pixel and ext
buffer APIs. I would like to know your feedback before we settle the
problem with the ext pixel format.
--
Hsia-Jun(Randy) Li
