Hi Bruce, On Thursday 28 May 2009 20:21:38 bruce m beach wrote: > Hello Laurent > > > On Wednesday 20 May 2009 05:29:27 bruce m beach wrote: > > > Okay. Here's what I have done to the code in luvcview ... > > > ... ... > > > ... ... > > > uvcGrab: ret=ioctl(vd->fd, VIDIOC_DQBUF, &vd->buf); (BEFORE THE CALL): > > > ... ... ^^^^^^ ^^^ ^^^^ > > > camera data by whatever method). The call is completed once, some other > > > stuff is executed, it is entered again, calls > > > > > > ret=ioctl(vd->fd, VIDIOC_DQBUF, &vd->buf) > > > > > > and never returns. It stays in the call until kill -9 luvcview(PID) > > > is executed. > > > ... ... One question is why doesn't it time out? > > > > The V4L2 specification doesn't specify if and when VIDIOC_DQBUF should > > timeout. Why would you like it to timeout ? > > Maybe it shouldn't timeout, but some kind of check should be made > in userland. A common complaint on the web is that programs (including > luvcview) do not respond to normal program exit or "cntrl-C". The > only way to terminate is "kill -9 pid".
kill -3 (ctrl-\) or -15 should work as well. > I believe that if something goes wrong and the camera doesn't start > streaming then it gets stuck in this ioctl(VIDIOC_DQBUF) and waits > forerever. The capture example from the uvc api uses "select" to monitor > buffers and dies with > > sh-4.0# capture_example > select timeout > > and I believe mplayer also uses the same mechanism > > sh-4.0# mplayer tv:// > Starting playback... > v4l2: select timeout > v4l2: select timeout ??% ??,?% 0 0 > v4l2: select timeout ??% ??,?% 0 0 > v4l2: select timeout ??% ??,?% 0 0 > v4l2: 1 frames successfully processed, 0 frames dropped. > Exiting... (Quit) select() is the right way to go if you need timeouts. When the application receives a SIGINT signal (ctrl-C) the uvcvideo driver will return from VIDIOC_DQBUF with -ERESTARTSYS. The ioctl is then called again immediately by the standard C library. > > > I have another webcam (0c45:6009 Microdia VideoCAM ExpressII) that uses > > > "modprobe sn9c102" to work. If I run it with luvcview it is only gives > > > a green screen but the uvcGrab looping works and it terminates > > > normally. I have another program (sn-webcam) where the ExpressII works > > > okay. > > > > That's a completely different driver, and I'm not familiar with it, > > sorry. > > My interest in it was that it wasn't getting stalled int the VIDIOC_DQBUF > ioctl call. I'm not clear what should work and what shouldn't work with > luvcview. Given that everything was working properly and I used a camera > using the sn9c102 driver which of the 3 possiblilities would you pick > > 1) Definitely should work > 2) Not in a million years. > 3) Might work depending on whatever it depends on. I'd go for 3. luvcview still has bugs, and should use a select() main loop. > > > By the way doing "make" on luvcview gives a lot of redefinitions like: > > > ... > > > > I assume you get those warnings with the deprecated SVN version. > > Don't use it, it's really deprecated. > > Good thing I mentioned it then. I went to > > http://svn.quickcamteam.net/svn/luvcview/trunk/luvcview/ > > which I assume is the current version. It compiles without the warnings > and seems to work a little bit better. Oops, sorry, I spoke too fast. The uvcvideo SVN version is deprecated. luvcview isn't. > > The reason why VIDIOC_DQBUF fails to return is probably that the driver > > doesn't get enough data from the camera to fill a frame (or that it > > believes it doesn't). > > One question is after the first frame does it get any data at all > and is ioctl(VIDIOC_STREAMON) really happening. As the green led on your camera turns on I suppose the video stream really starts. > > Could you set the trace level to 255, run luvcview for a few > > seconds, kill it(ctrl-\ should do the job) > > Never saw this one before but it works. Live and learn. > > > and send me the messages printed by the uvcvideo driver to the kernel log > > ? > > Okay. I insert the following messages in the kernel log at the > approprate times > > MESSAGE modprobe uvcvideo trace=255 > MESSAGE starting luvcvideo > MESSAGE cntrl backslash > MESSAGE done > > here is the output from luvcview > > sh-4.0# luvcview > luvcview 0.2.5 > SDL information: > Video driver: x11 > A window manager is available > Device information: > Device path: /dev/video0 > Stream settings: > Frame format: MJPG > Frame size: 640x480 > Frame rate: 30 fps > ^\Quit > > and below is the output from the kernel log. > > MESSAGE modprobe uvcvideo trace=255 [snip] > May 28 10:53:26 lapsystemx kernel: uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON) > May 28 10:53:26 lapsystemx kernel: uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) > May 28 10:53:28 lapsystemx kernel: uvcvideo: Frame complete (overflow). > May 28 10:53:28 lapsystemx kernel: uvcvideo: Dropping payload (out of sync). > May 28 10:53:28 lapsystemx last message repeated 18 times > May 28 10:53:28 lapsystemx kernel: uvcvideo: Dequeuing buffer 0 (3, 307789 bytes). > May 28 10:53:28 lapsystemx kernel: uvcvideo: uvc_v4l2_ioctl(VIDIOC_QBUF) > May 28 10:53:28 lapsystemx kernel: uvcvideo: Queuing buffer 0. > May 28 10:53:28 lapsystemx kernel: uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) > May 28 10:53:28 lapsystemx kernel: uvcvideo: Dropping payload (out of sync). > May 28 10:53:59 lapsystemx last message repeated 30784 times > May 28 10:55:00 lapsystemx last message repeated 60992 times > MESSAGE cntrl backslash > May 28 10:55:24 lapsystemx last message repeated 24351 times > May 28 10:55:24 lapsystemx kernel: uvcvideo: uvc_v4l2_release > MESSAGE done It seems the device doesn't toggle the FID bit in the UVC packet header. Could you try loading the driver with quirks=16 ? Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
