Hi John,
On Monday 12 January 2009, John Mathew wrote:
> Dear UVC Developers,
>
> [Sorry for the second message, the earlier message was an HTML
> formatted message, sorry!]
>
> I am working on developing a UVC camera. The camera itself runs linux
> kernel and uses the gadget mode. We have a gadget driver written and an
> application running on the device, which pushes data over USB to the host
> when host requests data. The camera works in Isochronous mode and copies
> 1024 bytes every microframe.
>
> With a bit of effort (which mostly involved correcting some of the
> descriptor values on the device side), I could get uvcvideo driver on the
> host to work with the camera. luvcview works fine, so is a simpe gstreamer
> viewer which uses the v4l2src element.
Congratulations. Do you plan to publish the driver's source code ?
> We would like to get the camera working well with the uvcvideo and is
> completely standards compliant.
>
> Below are some of the issues observed, I would appreciate any tips to debug
> the issue.
>
> The kernel message on the host says that the the uvcvideo invokes quirks=1.
>
> kernel: [88819.299222] uvcvideo: Forcing device quirks 0x1 by module
> parameter for testing purpose.
> kernel: [88819.299227] uvcvideo: Please report required quirks to the
> linux-uvc-devel mailing list.
>
> I am wondering why quirks was turned on to a value of 1 and see what can be
> done at the device side to fix it.
This simply means you set the quirks parameter to 1 when loading the driver,
either manually ('modprobe uvcvideo quirks=1') or automatically
(in /etc/modules.conf or /etc/modules.d/).
The quirks parameter is used to test various driver quirks without requiring a
recompilation. UVC compliant cameras shouldn't require any quirk.
> I am using gstreamer to stream from the camera and display the frames. with
> the pipeline arranged as follows.
>
> gst-launch v4l2src ! jpegdec ! ffmpegcolorspace ! xvimagesink
>
> I see that the gstreamer quits after streaming for afew hours saying that
> there is an error in the JPEG stream. It looks like some corruption is
> happening to the JPEG frames inside the camera. But I see no USB messages
> on the host or the device. To narrow down the problem, we have an
> application which takes one JPEG image and keep streaming them
> continuously, instead of using the ones from the camera. This probably will
> validate the USB data path.
>
> It will be great if uvc developers can throw some light on how to debug
> these issues.
Isochronous transfers are not guaranteed to be faultless. The driver could
print a message in the kernel log when an isochronous packet transfer fails,
but this currently require the UVC_TRACE_FRAME trace level, which would flood
your kernel log.
You can modify the uvc_trace(UVC_TRACE_FRAME, ...) statement at the beginning
of uvc_video_decode_isoc() in uvc_video.c and replace it with
uvc_printk(KERN_INFO, ...) to get the driver to print the message regardless
of the trace level.
I'm not sure if the EHCI controller and the USB stack report all isochronous
transfer errors to the driver, so the message might not get printed even if a
packet is corrupted or lost. However, this is worth trying.
Best regards,
Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
