Mem type gets lost on the way ?

[Ralph spitzner]

I've tried to get the driver to work with various applications
(Skype, kopete what have you) to no avail.

Then I tried the capture.c example from the v4l page.
The captest gets an "invalid argument" error on

xioctl (fd, VIDIOC_QUERYBUF, &buf)

While digging a bit deeper into this I found the following:
===========================================================
if (-1 == xioctl (fd, VIDIOC_QUERYBUF, &buf))
{
printf("TYPE = %x MEM= %x\n",buf.type,buf.memory);
errno_exit ("VIDIOC_QUERYBUF");
}
============= produces ====================================
bash-3.1# ./a.out
Supported formats:
S920 SN9C20X I420 (YUV 4:2:0)
BA81 Bayer 8bit (BGGR)
JPEG JPEG (YUV 4:2:2)
RGB3 RGB3
BGR3 BGR3
YU12 YU12
YV12 YV12
call 3,c0445609,bfeec71c
TYPE = 1 MEM= 1
VIDIOC_QUERYBUF error 22, Invalid argument
============================================================

clearly memtype is set to 1 here, then at the module side:

(sn9c20x-v4l2.c 74% L1142)
============================================================
UDIA_DEBUG("QUERY BUFFERS %d %d TYPE=%x MEM=%x\n",
buffer->index, dev->queue.count,buffer->type,buffer->memory);

if (buffer->memory != V4L2_MEMORY_MMAP ||
buffer->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
return -EINVAL;

============== gets me =====================================

[79584.679563] sn9c20x: v4l_sn9c20x_ioctl 08
[79584.679567] sn9c20x: Freeing 0 v4l2 buffers
[79584.679805] sn9c20x: Buffers Allocated 4
[79584.679807] SN9C20x USB 2.0 Webcam Driver: VIDIOC_REQBUFS count=4,
type=vid-cap, memory=mmap
[79584.679877] sn9c20x: v4l_sn9c20x_ioctl 09
[79584.679880] sn9c20x: QUERY BUFFERS 0 4 TYPE=1 MEM=0
[79584.679883] SN9C20x USB 2.0 Webcam Driver: VIDIOC_QUERYBUF error -22
[79584.681708] sn9c20x: Isoc cleanup
[79584.681712] sn9c20x: Freeing 4 v4l2 buffers

=============================================================

So somewhere inbetween the type of the memorybuffer seems to get lost.
It can't be an #include/#define issue since we're looking at absolute
numbers.

cat /dev/video0 happily produces text garbage of whatever the cam might
see :-)

==============================================================
bash-3.1# ldd a.out
linux-gate.so.1 => (0xb7f2e000)
/usr/local/lib/libv4l/v4l2convert.so (0xb7f2b000)
libc.so.6 => /lib/libc.so.6 (0xb7da2000)
libv4l2.so.0 => /usr/local/lib/libv4l2.so.0 (0xb7d99000)
/lib/ld-linux.so.2 (0xb7f2f000)
libv4lconvert.so.0 => /usr/local/lib/libv4lconvert.so.0
(0xb7d33000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7d1b000)
librt.so.1 => /lib/librt.so.1 (0xb7d11000)

libv4l is versioned 0.5.97 (same result with 0.5.8)

Any zen on this one ?

regards
-rasp

--
Woman inspires us to great things, and prevents us from achieving them.
-- Dumas

[Ralph spitzner]

Ralph spitzner wrote:
> (sn9c20x-v4l2.c 74% L1142)
> ============================================================
> UDIA_DEBUG("QUERY BUFFERS %d %d TYPE=%x MEM=%x\n",
> buffer->index, dev->queue.count,buffer->type,buffer->memory);
>
> if (buffer->memory != V4L2_MEMORY_MMAP ||
> buffer->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
> return -EINVAL;

Strange to reply to myself ;-)

If I comment out the check above completely, the cam works just fine.
I still haven't figured out where the '1' gets lost, though.....

[Gray Water]

I'm sorry there was no reply earlier.

Thing is - I don't understand the mechanism either and had not yet time to take a more careful look at it.

Anyway - great it works for you now.

GWater

2009/5/5 Ralph spitzner <ra...@spitzner.org>

[Vasily Khoruzhick]

On Sunday 03 May 2009 13:34:05 Ralph spitzner wrote:
> I've tried to get the driver to work with various applications
> (Skype, kopete what have you) to no avail.
>
> Then I tried the capture.c example from the v4l page.
> The captest gets an "invalid argument" error on

> <skipped>

> libv4l is versioned 0.5.97 (same result with 0.5.8)
>
> Any zen on this one ?
>
> regards
> -rasp

The thing is memory got overwritten in videobuf-core.c, 249, function
videobuf_status().

I've checked out other drivers and no driver checks for memory ==
V4L2_MEMORY_MMAP in querybuf ioctl (even uvc) (I'm using 2.6.30_rc4-git1)

So here's a fix in attachment: 0003-Don-t-check-memory-type-in-querybuf-
ioctl.patch

Regards
Vasily

[Ralph spitzner]

Vasily Khoruzhick wrote:
>
> The thing is memory got overwritten in videobuf-core.c, 249, function
> videobuf_status().
>
> I've checked out other drivers and no driver checks for memory ==
> V4L2_MEMORY_MMAP in querybuf ioctl (even uvc) (I'm using 2.6.30_rc4-git1)
>
> So here's a fix in attachment: 0003-Don-t-check-memory-type-in-querybuf-
> ioctl.patch
>
> Regards
> Vasily
>

Since I'm just reading this group/list someone should get that
patch into the driver. it'll probably fix some 22 EINVAL errors
I've googled up from/for people using different cams, but the sn9c20x
driver....

[Brian Johnson]

But our driver doesn't use the videobuf functions so that shouldn't be
where its getting overwritten.

But yeah it should not be checked since it is not an input variable,
it should however according to the specs be set to MMAP by this ioctl
however.

[Vasily Khoruzhick]

On Wednesday 06 May 2009 10:05:20 Brian Johnson wrote:
> But our driver doesn't use the videobuf functions so that shouldn't be
> where its getting overwritten.

Uh, I'm wrong here :)