Hi Hans, On Tuesday 29 September 2009 09:04:04 Hans de Goede wrote: > On 09/29/2009 12:55 AM, Laurent Pinchart wrote: [snip] > > That's the right way to do it, and it should work. > > > > ioctl(VIDIOC_S_FMT) > > ioctl(VIDIOC_REQBUFS - n buffers) > > mmap() > > ioctl(VIDIOC_QBUF) > > ioctl(VIDIOC_STREAMON) > > ioctl(VIDIOC_DQBUF) > > ioctl(VIDIOC_QBUF) > > ... > > ioctl(VIDIOC_STREAMOFF) > > munmap() > > ioctl(VIDIOC_REQBUFS - 0 buffers) > > Note that the need for this last call (VIDIOC_REQBUFS - 0 buffers), also > known as unrequesting the buffers, is a bit ambiguous. Not all drivers > need this, and some even return an EINVAL if the number of requested > buffers < 0.
The number of buffers can't be < 0 as it's a __u32. Drivers will see a huge integer, and should lower the number of requested buffers instead of returning -EINVAL. Or did you mean they return EINVAL when the number of buffers is == 0 ? In that case they should really be fixed to free the buffers. > I think we need to clarify the V4L2 API specification on this point. I agree. v4l2_requestbuffers::count is documented as being used for V4L2_MEMORY_MMAP only, and drivers use it for V4L2_MEMORY_USERPTR as well. This needs to be fixed in the spec too. > libv4l currently does do the unrequest the buffers thingie (when it is > managing the buffers itself), but ignores the return value. Do you know which drivers fail to free the buffers when the requested value is equal to zero ? -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
