Hi Natalie, Sorry not to have answered sooner. I've been busy with real life for a whole week.
On Thursday 31 May 2007, Natalie Protasevich wrote: > 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. Good news :-) > > > > 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. V4L2 maps buffer individually, while V4L2 maps them in a single call. This is why VIDIOCGMBUF calls can't be translated automatically by the V4L1 compatibility layer but must be handled by drivers. It shouldn't be too difficult to come up with a V4L1 compatibility patch, but I'm not too keen on including it in the driver. V4L1 is deprecated, and applications should really move on to V4L2. If drivers implement V4L1 compatibility, application developers will just stick with V4L1 for longer. > > 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. > > 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... V4L2 specifies 3 I/O methods to move data from kernel space to user space. The first I/O method is plain read(), which the Linux UVC driver doesn't implement yet. The second and third I/O methods are very similar. The kernel writes data in video buffers which are mapped to userspace using mmap(). Userspace applications then use the VIDIOC_DQBUF ioctl to wait until a buffer is ready, and then proceed to read the data directly from the memory buffer. This is much more efficient than read() calls, and is referred as streaming I/O. Drivers can implement one or all I/O methods regardless of device capabilities. I decided to implement the mmap streaming I/O method first as this was the most efficient one, and the one used by most userspace applications. Implementing read() support is certainly possible and wouldn't be that difficult. > (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. If your V4L1 software uses read() to retrieve video data, implementing read support would indeed be more useful than implementing VIDIOCGMBUF. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
