On Mon, Mar 10, 2014 at 12:21 AM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > On 03/10/2014 08:02 AM, m silverstri wrote: >> Hi, >> >> I am studying v4l2 m2m driver example. I want to know why the set >> format function in the example fails when it is called again after >> user application req_buf? In set format function checks for >> vb2_is_busy(vq) and that function returns true after user space app >> calls req_buf. >> >> For example in here: >> http://stuff.mit.edu/afs/sipb/contrib/linux/drivers/media/platform/mem2mem_testdev.c >> >> static int vidioc_s_fmt(struct m2mtest_ctx *ctx, struct v4l2_format *f) >> { >> //... >> // Check for vb2_is_busy() here: >> if (vb2_is_busy(vq)) { >> v4l2_err(&ctx->dev->v4l2_dev, "%s queue busy\n", __func__); >> return -EBUSY; >> } >> //... >> } >> >> Why the driver prevents user space application change format after it >> request buffers? > > When you request the buffers they will be allocated based on the current format. > Changing the format later will mean a change in buffer size, but once the buffers > are allocated that is locked in place. It's generally a bad idea to, say, increase > the image size and then watch how DMA overwrites your memory :-) > > This is not strictly speaking a v4l limitation, but a limitation of almost all > hardware. It is possible to allow format changes after reqbufs is called, but > that generally requires that the buffers all have the maximum possible size > which wastes a lot of memory. And in addition you would have to have some sort > of metadata as part of the captured frame so you know the actual size of the > image stored in the buffer. > > None of the drivers in the kernel support this, BTW. > > Regards, > > Hans Hans, Thank you. Regards, Mike -- 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
