Re: [V4l2-library] Messed up syscall return value

Mauro Carvalho Chehab <[email protected]> Tue, 29 Jul 2008 17:51:12 -0300
Newsgroups gmane.comp.video.video4linux,gmane.linux.drivers.spca50x.devel
Message-ID <20080729175112.21f1560f@gaivota>
On Tue, 29 Jul 2008 21:05:17 +0200
Laurent Pinchart <[email protected]> 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

--
video4linux-list mailing list
Unsubscribe mailto:[email protected]?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list