Hi Bruce, On Thursday 04 June 2009 00:25:22 bruce m beach wrote:
[snip] > > > > It seems the device doesn't toggle the FID bit in the UVC > > packet header. Could you try loading the driver with > > quirks=16 ? > > First of all it sure looks light the camera is indeed streaming since I get > the line > > uvcvideo: Dequeuing buffer 0 (3, 307789 bytes) > > which is very close to the format > > 640x480=307200 + 589 control bytes (whatever they are) You're streaming in MJPEG so the data size can (and will) vary. The application is able to dequeue a single buffer only. This led me to believe that the driver is able to fill a single video buffer and then drops all further data (or doesn't receive any more data) for some reason. > Okay I tried the following command (and a million other variations) > > modprobe -v uvcvideo trace=255 quirks=16 > > and got the line from the kernel log > > kernel: uvcvideo: Forcing device quirks 0x10 > by module parameter for testing purpose. What bothers me in the trace is 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 May 28 10:55:24 lapsystemx last message repeated 24351 times The "out of sync" message means that the device didn't toggle the FID bit. Quirk 0x10 is supposed to work around that by ignoring the FID bit. > This has no effect at all, same output as the trace above, so I thought it > might be a good idea to see what was happening in the header. Now if I went > to the wrong place then all my data is wrong. > > I went to the call > > "static int uvc_video_decode_start" > > in the file "uvc_video.c" > > I added the lines > > __u8 packet_header; > packet_header=data[1] & 255; > > uvc_trace(UVC_TRACE_FRAME, "packet header=%d\n", > packet_header); > > After compiling, installing and reloading > I immediately got many pages of > > packet header=141 > > so I tried the following, see if the header ever changes. > > if (packet_header != 141) > uvc_trace(UVC_TRACE_FRAME, "packet header=%d\n", > packet_header); > > which never got printed. In other words the packet header is > always 141 and we have the information below > > UVC_STREAM_EOH (1 << 7) 1 (set) > UVC_STREAM_ERR (1 << 6) 0 (reset) > UVC_STREAM_STI (1 << 5) 0 (reset) > UVC_STREAM_RES (1 << 4) 0 (reset) > UVC_STREAM_SCR (1 << 3) 1 (set) > UVC_STREAM_PTS (1 << 2) 1 (set) > UVC_STREAM_EOF (1 << 1) 0 (reset) > UVC_STREAM_FID (1 << 0) 1 (set) EOF should be set at the end of every frame, and FID should be toggled for every frame. The other bits look correct. Could you please print the packet length as well as the header flags ? I'd like to know if the driver isn't supplied with data at all, or if it drops it for some reason. Best regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list [email protected] https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
