On 5/25/07, Natalie Protasevich <[EMAIL PROTECTED]> wrote:
Hi Laurent, > V4l: device has no mmap support > > ioctl VIDIOCSWIN: Input/output error > > ioctl VIDIOCGWIN: Invalid argument > > ioctl VIDIOCGCHAN: Invalid argument > > ioctl VIDIOCGWIN: Invalid argument > > yuvgrab, read failed! > > yuvgrab, read failed! > > yuvgrab, read failed! > > Those ioctls are from the V4L1 API, which the Linux UVC driver doesn't > support. It might be possible to use the V4L1 compatibility layer, and > that's > probably what you're doing already (maybe without even being aware) if > Marratech works on a 32 bits machine. In that case, there might be some > issues with the V4L1 compatibility layer on 64 bit architectures. That is exactly what I am suspecting... > uvccapture and luvcview: > > > > [EMAIL PROTECTED]:/tmp$ ./uvccapture > > sending ioctl VIDIOC_QUERYCAP > > sending ioctl VIDIOC_S_FMT > > Unable to set format: 22. > > Init v4L2 failed !! exit fatal > > Those are definitely V4L2 calls. -22 means invalid argument. There might > again > be some issue with 64 bit architectures, either in the driver or in > luvcview. > I can't help you much as I have no 64 bit machine to test this on. Actually, I am happy to report that the latest kernel patches have resolved this issue. > I also have a kernel trace with my debug, this is a part of it that > shows > > that the driver calls into the l1 compat layer, which seems odd to me > since > > everything from application to kernel is all l2: > > compat_ioctl32 is the 32bit/64bit compatibility layer, not the V4L1 > compatibility layer. With new updates to the kernel videodev and compat_ioctl32 layer we can run UVC cameras very nicely, using applications like luvcview, it works just great. However, the problem is that we would like to use conferencing software that is written to support old v4L1 mechanism, and the rewrite is going on...slowly :) But the V4L1 compat layer it it was working could be a solution for the time being. I tracked couple first ioctl's that fail without proper support/translation in the v4l_compat_ioctl32 - those are VIDIOCGMBUF and VIDIOCGCHAN. I am not sure if it is feasible/easy to implement those, the latter one seems to be just a matter of filling out a structure according to the camera's features, but the memory mapped buffer looks a bit challenging. Although looking at the way it is implemented in videodev - it seems possible to do something similar. I would really appreciate your opinion on this problem.
Laurent, I'm taking this back. With a closer look the software seems to assume that device is capable of read and mmap, whereas the new Logitech cams are streaming devices, so they can't really do read from the user mmaped buffer...(am I right?) So since the software doesn't implement streaming (it turns it off in fact), and doesn't call QBUF, DQBUF etc. instead it's just sending reads that fail of course. So there is no really a point to implement VIDOCGMBUF as I think I understand now. Thanks, --Natalie
_______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
