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 -- 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
