On Tuesday 29 July 2008, Mauro Carvalho Chehab wrote:
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.
The documentation clearly states that the ioctl returns 0 on success, not the number of allocated buffers. Applications that have been developed from the spec will not break. Applications that rely on the wrong return value have been developed in violation of the spec.
This situation is analogous to using a structure with a reserved field that is clearly marked as "don't touch" by the spec. If an application relies on the reserved field being set to a specific value, you will surely not refrain from changing that value in the kernel because it would break the application.
Best regards,
Laurent Pinchart