Le mercredi 22 mars 2023 à 17:01 +0200, Laurent Pinchart a écrit : > On Wed, Mar 22, 2023 at 10:50:52AM -0400, Nicolas Dufresne wrote: > > Hi Laurent, > > > > Le lundi 20 mars 2023 à 01:33 +0200, Laurent Pinchart a écrit : > > > > The typical usage is that applications allocate N buffers with the > > > > VIDIOC_REQBUFS ioctl, and in most cases that's all they use. > > > > > > Note that once we get DELETE_BUF (or DELETE_BUFS) support I'd like to > > > encourage applications to use the new API, and deprecate REQBUFS > > > (dropping it isn't on my radar, as it would take forever before no > > > userspace uses it anymore). > > > > I was wondering if you can extend on this. I'm worried the count semantic might > > prevent emulating it over create_bufs() ops, but if that works, did you meant to > > emulate it so driver no longer have to implement reqbufs() if they have > > create_bufs() ? > > For drivers it should be fairly simply, as the reqbufs and create_bufs > ioctl handlers should just point to the corresponding videobuf2 helpers. > > What I meant is that I'd like to encourage userspace to use the > VIDIOC_CREATE_BUFS ioctl instead of VIDIOC_REQBUFS. > I'm not sure what rationale I can give implementer to "encourage" them to use a more complex API that needs to copy over the FMT (which has just been set), specially in the initial pre-allocation case. For most, CREATE_BUFS after SMT will look like a very redundant and counter intuitive thing. Maybe you have a more optimistic view on the matter ? Or you have a better idea how we could give a meaning to having a fmt there on the initial case where the allocation matches the queue FMT ? Nicolas
