On Tue, 29 Jul 2008 21:05:17 +0200 Laurent Pinchart laurent.pinchart@skynet.be wrote:
So, it returns the number of buffers that were really allocated. It is too late to change this, since this behaviour is very old. If the V4L2 API spec is different, we should fix at the spec, not at the driver.
I'm not sure to agree with that. The spec clearly states that 0 is returned on success and -1 on error. Since applications don't choke with the currently buggy videobuf-core implementation, they must all be check against -1, or checking for a negative error code. So returning 0 shouldn't break any application, except if it relies on the ioctl returning the number of buffers, which is not documented anywhere.
There are some apps that relies on the number of buffers allocated. This is important on some cases. For example, if you have digital audio support, userspace app needs to know how much buffers were allocated, in order to proper synchronize audio and video.
In the case of videobuf, used by most drivers since pre-2.6 kernels, it returns it at both req->count and as the returned value for ioctl.
So, userspace apps may use req->count to know the effective number of allocated buffers, or the returned value for the ioctl. Since most apps were done considering bttv (a client of videobuf), I don't doubt that some of them are just using the returned value at the ioctl.
Cheers, Mauro