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

On Mon, Jul 28, 2008 at 11:56:32PM +0200, Jiri Slaby wrote:
> On 07/28/2008 11:49 PM, Gregor Jasny wrote:
> >I've observed strange behavior in the REQBUFS ioctl for the non-emulated
> >case.
> >
> >I've debugged the problem to the line:
> >result = syscall(SYS_ioctl, devices[index].fd, VIDIOC_REQBUFS, req);
> >
> >Here the value 2 get stored into result, although the kernel driver
> >returned success (at least it does not complain loudly in the logs).
> >
> strace and ltrace will help in this case I guess. Could you provide them for
> your testcases?

Sure:

ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fffbfd9fdd0) = 0
ioctl(3, VIDIOC_G_FMT or VT_SENDSIG, 0x7fffbfd9fd00) = 0
ioctl(3, VIDIOC_ENUM_FMT or VT_SETMODE, 0x7fffbfd9fc40) = 0
ioctl(3, VIDIOC_ENUM_FMT or VT_SETMODE, 0x7fffbfd9fc40) = -1 EINVAL (Invalid argument)
ioctl(3, VIDIOC_TRY_FMT, 0x7fffbfda0080) = 0
ioctl(3, VIDIOC_S_FMT or VT_RELDISP, 0x7fffbfd9fd40) = 0
ioctl(3, VIDIOC_REQBUFS or VT_DISALLOCATE, 0x7fffbfda0060) = 2

Huh? Something evils seems to be going on in V4L2 land.
I've spotted the following lines in videobuf-core.c:videobuf_reqbufs

        req->count = retval;

 done:
        mutex_unlock(&q->vb_lock);
        return retval;

That would explain the retval '2'. It seems a retval = 0; statement is missing here for the success case.

Gregor

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