Hi Michael, On Monday 14 November 2011 20:20:12 Michael Tandy wrote: > I did some more experiments with this webcam, and with a nasty hack > got it working. > > Basically the problem seems to be the frame interval requested. If I > replace line 175 of uvc_v4l2.c [1] with > > probe->dwFrameInterval = 2500000; > > the camera works fine in mjpeg mode. > > The frame interval behaves oddly in this camera, in that if you set > the frame interval above a certain threshold the camera seems to > ignore it and send frames at whatever rate it feels like, but if you > set it below a certain threshold the camera exhibits the bug I've > described above, sending back corrupted frames and error codes. Most > likely a firmware bug, as I can't imagine anyone would design a camera > to function that way. > > I assume we wouldn't be inclined to patch the kernel to deal with this > one camera's weird behaviour?
That could be done, but it would likely require something different than the current quirks system. What is the frame interval threshold value for the device ? > [1] > http://lxr.free-electrons.com/source/drivers/media/video/uvc/uvc_v4l2.c?v= > 2.6.28#L175 > > > On 3 November 2011 10:20, Laurent Pinchart wrote: > > On Wednesday 07 September 2011 08:11:48 Alexey Fisher wrote: > >> Am 06.09.2011 12:53, schrieb Michael Tandy: > >> > [99317.553237] uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON) > >> > [99317.554747] uvcvideo: uvc_v4l2_poll > >> > [99333.472385] uvcvideo: Dropping payload (error bit set). > >> > [99333.472389] uvcvideo: Frame complete (EOF found). > >> > [99333.472391] uvcvideo: EOF in empty payload. > >> > [99333.472429] uvcvideo: uvc_v4l2_poll > >> > [99333.472438] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) > >> > [99333.472447] uvcvideo: Dequeuing buffer 0 (3, 2676 bytes). > >> > >> hmm... the camera notify us about with error bit set, but current driver > >> will just drop it and mark the buffer as faulty. > > > > As the data can't be trusted, the uvcvideo driver decides to drop the > > packet. Alternatively the packet could be processed normally and the > > buffer market as bad. It would then be up to the application to decide > > what to do with such buffers (you will have to set the no_drop module > > parameter to 1, as the driver drops faulty buffers by default). > > > > The following patch should implement that behaviour, in case you want to > > test it. > > > > diff --git a/drivers/media/video/uvc/uvc_video.c > > b/drivers/media/video/uvc/uvc_video.c index ffd1158..baa5850 100644 > > --- a/drivers/media/video/uvc/uvc_video.c > > +++ b/drivers/media/video/uvc/uvc_video.c > > @@ -419,13 +419,6 @@ static int uvc_video_decode_start(struct > > uvc_streaming *stream, if (len < 2 || data[0] < 2 || data[0] > len) > > return -EINVAL; > > > > - /* Skip payloads marked with the error bit ("error frames"). */ > > - if (data[1] & UVC_STREAM_ERR) { > > - uvc_trace(UVC_TRACE_FRAME, "Dropping payload (error bit " > > - "set).\n"); > > - return -ENODATA; > > - } > > - > > fid = data[1] & UVC_STREAM_FID; > > > > /* Increase the sequence number regardless of any buffer states, > > so @@ -442,6 +435,13 @@ static int uvc_video_decode_start(struct > > uvc_streaming *stream, return -ENODATA; > > } > > > > + /* Mark the buffer as bad if the error bit is set. */ > > + if (data[1] & UVC_STREAM_ERR) { > > + uvc_trace(UVC_TRACE_FRAME, "Marking buffer as bad (error > > bit " + "set).\n"); > > + buf->error = 1; > > + } > > + > > /* Synchronize to the input stream by waiting for the FID bit to > > be * toggled when the the buffer state is not UVC_BUF_STATE_ACTIVE. * > > stream->last_fid is initialized to -1, so the first isochronous -- Regards, Laurent Pinchart _______________________________________________ Linux-uvc-devel mailing list Linux-uvc-devel@lists.berlios.de https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
