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