Hi, On 09/30/2009 05:59 PM, Laurent Pinchart wrote: > 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. >
Yes I meant < 1, so == 0, sorry. >> 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 ? > I wanted to answer atleast gspca, but that seems to have been fixed :) So maybe I'm wrong and now a days most drivers do support the unrequest. Regards, Hans _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
