Hi Michael, On Thursday 26 July 2012 16:22:17 Michael Jones wrote: > On 07/26/2012 04:05 PM, Laurent Pinchart wrote: > > On Thursday 26 July 2012 13:59:54 Michael Jones wrote: > >> Hello, > >> > >> I would like to (re)submit a couple of patches to support V4L2 behavior > >> at the V4L2 device nodes of the omap3-isp driver, but I'm guessing they > >> require some discussion first. > > > > Indeed. > > > > The main reason why the OMAP3 ISP driver implements G_FMT/S_FMT as it does > > today is to hack around a restriction in the V4L2 API. We needed a way to > > preallocate and possibly prequeue buffers for snapshot, which wasn't > > possible in a standard-compliant way back then. > > > > The situation has since changed, and we now have the VIDIOC_CREATE_BUFS > > and VIDIOC_PREPARE_BUF ioctls. My plan is to > > > > - port the OMAP3 ISP driver to videobuf2 > > - implement support for CREATE_BUFS and PREPARE_BUF > > - fix the G_FMT/S_FMT/ENUM_FMT behaviour > > What will the G_FMT/S_FMT/ENUM_FMT behavior be then? Can you contrast > it with the behavior of my patches? If the behavior will be the same > for user space, and your proposed changes won't be in very soon, can we > use my patches until you make your changes? At the moment the driver accepts any format you give it in a S_FMT call, regardless of the format of the connected pad. The reason for that is to allow VIDIOC_REQBUFS to allocate buffers for an arbitrary size. With CREATE_BUFS and PREPARE_BUFS support, G_FMT, S_FMT and ENUM_FMT should return the format of the connected pad. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
