On 24/03/2023 16:14, Nicolas Dufresne wrote: > 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 ? I wouldn't mind if we can make a much nicer CREATE_BUFS variant with just the size instead of a format. That was in hindsight a really bad idea, terrible over-engineering. Regards, Hans
