Hi Ramesh,

sorry for the late reply.

On Wednesday 11 November 2009 12:43:38 Ramesh Rajagopal wrote:
> Hi Laurent,
>
> Thank you for the reply. The webcam  is linux based and I am using the
> UVC gadget driver of linux kernel 2.6.10.
> In this kernel I don't see any example doing UVC bulk transfer. It is
> working perfectly with ISOC.
> Can you please let me know, if there is any example code that does UVC bulk
> transfer ? I couldn't find it any.

The UVC gadget driver I wrote uses isochronous transfers. It should be 
possible to use bulk transfers by modifying the driver, but there's no code 
sample that I'm aware of.

> The uvc specification is not clear enough to distinguish ISOC and BULK
> transfer atleast from my understanding.
> 
> While doing ISOC transfer, we have an alternate Interface Setting, when we
> get a SET_INTERFACE we start transferring the UVC header first alone to
> start the transfer. There after each IN token from host will carry the
> frames if any, otherwise header alone goes.
> 
> In case of BULK, with alternate settings, the host machine hangs.
> SET_INTERFACE (alternateSetting set 1), Why is it like that?

According to the UVC specification, streaming interfaces with bulk endpoints 
don't use alternate settings.

This is actually a problem, as the UVC specification doesn't provide any way 
for bulk devices to detect when the host starts and stops streaming.

> So I removed alternate settings and till enumeration it is proper. Then
> After I get VS_PROBE_COMMIT from the host, I start transferring exactly
>  same like ISOC, but
> I don't see any video on the host and no more proceedings from here. The
> data is not going from the FIFO, hence I am not getting any more TX
> interrupt from my device.
> 
> I am attaching my devices descriptor as well as host side logs. Please find
> the attachment. Please let me know, is there any link talk about BULK
> transfer or example.

The descriptors look correct at first glance. The log shows that the driver 
doesn't receive any bulk packet (assuming the trace parameter has been set to 
255). This seems to indicate a low-level problem, probably on the device side. 
My guess is that the device doesn't sent bulk packets. That would be easy to 
verify if you have access to a USB analyzer. If the assumption is correct, the 
problem is on the device side.

-- 
Regards,

Laurent Pinchart
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel

Reply via email to