On 5/16/19 11:56 AM, Tomasz Figa wrote: > On Thu, May 16, 2019 at 5:09 PM Stanimir Varbanov > <stanimir.varbanov@xxxxxxxxxx> wrote: >> >> Hi Hans, >> >> On 5/14/19 11:54 AM, Hans Verkuil wrote: >>> Hi Stanimir, >>> >>> On 4/12/19 5:59 PM, Stanimir Varbanov wrote: >>>> This changes v4l2_pix_format and v4l2_plane_pix_format sizeimage >>>> field description to allow v4l clients to set bigger image size >>>> in case of variable length compressed data. >>> >>> I've been reconsidering this change. The sizeimage value in the format >>> is the minimum size a buffer should have in order to store the data of >>> an image of the width and height as described in the format. >>> >>> But there is nothing that prevents userspace from calling VIDIOC_CREATEBUFS >>> instead of VIDIOC_REQBUFS to allocate larger buffers. >> >> Sometimes CREATEBUFS cannot be implemented for a particular fw/hw. >> >> CC: Tomasz for his opinion. >> > > Thanks Stanimir. > > Actually, if called at the same point in time as REQBUFS, CREATE_BUFS > doesn't really differ to much, except that it gives more flexibility > for allocating the buffers and that shouldn't depend on any specific > features of hardware or firmware. > > Actually, one could even allocate any buffers any time regardless of > hardware/firmware support, but the ability to use such buffers would > actually depend on such. > > Perhaps we should just let the drivers return -EBUSY from CREATE_BUFS > if called at the wrong time? > >>> >>> So do we really need this change? >>> > > Yes, because this has worked like this all the time, but it was just > not documented. Disallowing this would break quite a bit of existing > userspace. Which drivers allow this today? I think that would be useful information for the commit log of a v4 of this patch. Regards, Hans > > Best regards, > Tomasz > >>> The more I think about this, the more uncomfortable I become with this change. >>> >>> Regards, >>> >>> Hans >>> >> >> <cut> >> >> -- >> regards, >> Stan
