Hi Ricardo, On Sunday 11 May 2008, Ricardo Ferreira wrote: > Hello, > > On Sunday 11 May 2008 11:06:46 Laurent Pinchart wrote: > > Hi Ricardo, > > > > On Sunday 11 May 2008, Ricardo Ferreira wrote: > > > Hi, thanks for the response, > > > > > > On Sunday 11 May 2008 09:15:05 Laurent Pinchart wrote: > > > > Hi Ricardo, > > > > > > > > On Wednesday 07 May 2008, Ricardo Ferreira wrote: > > > > > Hello all, > > > > > > > > > > I stumbled upon a problem when using your driver. It seems that it > > > > > blocks on the first VIDIOC_DQBUF ioctl. > > > > > > > > > > I first noticed it in my code using the latest debian > > > > > linux-uvc-source on an amd64 2.6.24 kernel. I assumed it was my > > > > > problem so I tried luvcview and noticed that there was always a 2 > > > > > second block the first time that same ioctl was called, but it > > > > > worked flawlessly after that. > > > > > > > > > > After grabing your latest svn driver, luvcview stopped working, > > > > > blocking on the first call to VIDIOC_DQBUF. > > > > > > > > > > I have an integrated webcam: > > > > > Bus 006 Device 003: ID 05c8:0103 Cheng Uei Precision Industry Co., > > > > > Ltd (Foxlink) > > > > > > > > > > since I never heard of this manufacturer, I tried a phillips > > > > > spc1000nc freshly bought. The results were exactly the same. > > > > > > > > > > Do you think it has to do with the driver, this particular kernel, > > > > > amd64 (had some other compatibility issues because of this in the > > > > > past), or anything else? > > > > > > > > Could you please retry with r206 and r207 and compare the results ? > > > > r207 introduces a patch to drop incomplete frames. > > > > > > Yes, that is exactly were it breaks. r206 has that 1-2 second delay the > > > first time DQBUF is called, but after that it is perfect. in r207 the > > > first call to DQBUF never returns. > > > > Thanks for your fast reply. > > > > > > If reverting to r206 helps, I'll ask you to try a patch to get more > > > > information about the issue. > > > > > > sure, whatever helps. > > > > I've attached a patch to this e-mail. Could you please apply it, load the > > driver with the trace parameter set to 143 and report the kernel log > > messages ? > > many of these keep repeating: > > uvcvideo: Frame complete (EOF found). > uvcvideo: EOF in empty payload. > uvcvideo: incomplete buffer (153600 bytes, expected 168960) > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Dropping payload (out of sync). > uvcvideo: Frame complete (EOF found). > uvcvideo: EOF in empty payload. > uvcvideo: incomplete buffer (153600 bytes, expected 168960) > > Anything else I can do?
Looks like a bug in the camera :-/ Could you try with different resolutions and report the number of bytes received and expected number of bytes for each resolution supported by the camera ? I'd appreciate if you could perform the test for both the Foxlink and Philips cameras. Please also post the output of lsusb -v for both cameras. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
