Hi Luca, > > poll() without read() makes sense, using VIDIOC_DQBUF. > > It has little sense. It looks like a mix of I/O methods from the user > point of view.
It isn't. The Linux UVC driver supports the streaming I/O with memory mapped buffers only. This is allowed by the V4L2 spec: "The V4L2 API deļ¬nes several different methods to read from or write to a device. All drivers exchanging data with applications must support at least one of them." (p. 44) read() support will be implemented later. Regarding poll(), V4L2 states that "All drivers implementing the read() or write() function or streaming I/O must also support the poll() function. See the poll() manual page for details." (p. 172) poll() support is thus required. > Furthermore, poll() does not seem to start to capture video data as > expected. This is a flaw. poll() is not expected to start to capture video data when using a streaming I/O method. You need to explicitely call VIDIOC_STREAMON. > I wonder how you can implement the code to start the video streaming and > integrate the resulting streaming with all the ioctl's related to the mmap() > I/O method described by the V4L2 protocol. > (VIDIOC_QUERYBUF fo istance). I'm not sure what you mean there. poll() must not start video streaming when using a streaming I/O method. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
