On 10/17/2018 10:57 AM, Laurent Pinchart wrote: > Hi Hans, > > On Thursday, 20 September 2018 17:42:15 EEST Hans Verkuil wrote: >> Some parts of the V4L2 API are awkward to use and I think it would be >> a good idea to look at possible candidates for that. >> >> Examples are the ioctls that use struct v4l2_buffer: the multiplanar support >> is really horrible, and writing code to support both single and multiplanar >> is hard. We are also running out of fields and the timeval isn't y2038 >> compliant. >> >> A proof-of-concept is here: >> >> https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer&id=a95 >> 549df06d9900f3559afdbb9da06bd4b22d1f3 >> >> It's a bit old, but it gives a good impression of what I have in mind. >> >> Another candidate is >> VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL/VIDIOC_ENUM_FRAMEINTERVALS: expressing >> frame intervals as a fraction is really awkward and so is the fact that the >> subdev and 'normal' ioctls are not the same. >> >> Would using nanoseconds or something along those lines for intervals be >> better? >> >> I have similar concerns with VIDIOC_SUBDEV_ENUM_FRAME_SIZE where there is no >> stepwise option, making it different from VIDIOC_ENUM_FRAMESIZES. But it >> should be possible to extend VIDIOC_SUBDEV_ENUM_FRAME_SIZE with stepwise >> support, I think. > > If we refresh the enumeration ioctls, I propose moving away from the one > syscall per value model, and returning everything in one (userspace-allocated) > buffer. The same could apply to all enumerations (such as controls for > instance), even if we don't address them all in one go. I'm not convinced about this, primarily because I think these enums are done at configuration time, and rarely if ever while streaming. So does it really make a difference in practice? Feedback on this would be welcome during the summit meeting. > >> Do we have more ioctls that could use a refresh? S/G/TRY_FMT perhaps, again >> in order to improve single vs multiplanar handling. > > If we refresh the G/S/TRY format ioctls (and I think we should), I would > propose moving to a G/S model with ACTIVE and TRY formats, as for subdevs. > This should make it easier to construct full device states internally, in > order to implement proper request API support for formats. We should then also > document much better how formats and selection rectangles interact. Interesting. I was planning a slide for this. >> It is not the intention to come to a full design, it's more to test the >> waters so to speak. > > Another item that we're missing is a way to delete buffers (the counterpart of > VIDIOC_CREATE_BUFS). As this will introduce holes in the buffer indices, we > might also need to revamp VIDIOC_CREATE_BUFS (which would give us a chance to > move away from the format structure passed to that ioctl). > I'm just writing the slide for that :-) Regards, Hans
