Hi Laurent,
I got little luck with UVC bulk transfer after changing the uvcvideo
driver. Now I am getting some frames on
the host side.
In the UVC driver, the
dwMaxPayloadSize(stream->ctrl.dwMaxpayloadTransferSize) of streaming control
variable is being assigned during the enumeration stage.
When we start the luvcview on the host side, this variable is being changed
to "0". This is happening in the call of uvc_v4l2_do_ioctl() with
VIDIOC_S_FMT as a "cmd"
variable.
The function uvc_v4l2_try_format function is copying values of
"bFrameIndex", "formatIndex" and "dwMaxFrameVideoSize" . But it does
re-initialize the dwMaxpayloadTransferSize to "0".
This one causes problem in the uvc_init_video_bulk() which takes
dwMaxpayloadSize for calculating number of URB packets which is becoming "0"
because of the above re-initialization.
When I applied the attached patch, I could get some frames on my host side.
Without this patch, it was failing on uvc_init_video_bulk() function.
I am not well familiar with UVC video driver. I don't know whether this is
the correct way of fixing this problem. I may need some help on this issue.
Please find the attachment. Please let me know, how can I proceed from here.
Thanks & Regards,
Ramesh.
On Wed, Nov 25, 2009 at 10:13 AM, Ramesh Rajagopal <shm...@gmail.com> wrote:
> Hi Laurent,
>
>
>> sorry for the late reply.
>>
>
> Thats fine.
>
>>
>> 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.
>>
>
> Does this mean, I have to change the musb gadget driver code? I changed my
> driver
> which registers with musb. I didn't chane anything on the musb gadget
> driver.
>
>
>>
>> > 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.
>>
>
> Do you aware when do I start sending packets to the host? In case of ISOC,
> we start sending packets
> when get SET_INTERFACE (enabling the alternate setting) request. Please let
> me know.
>
>
>>
>> > 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.
>>
>
> I see the packets are on the wire. USB Analyzer shows me the data and even
> I verified the header data,
> it looks correct, Now I am not getting back the ACK from the host. Thanks
> for your Reply.
>
>>
>> --
>> Regards,
>>
>> Laurent Pinchart
>>
>
> Regards,
> Ramesh.
>
>
>
diff -r c57f47cfb0e8 linux/drivers/media/video/uvc/uvc_v4l2.c
--- a/linux/drivers/media/video/uvc/uvc_v4l2.c Wed Nov 04 18:21:15 2009 -0200
+++ b/linux/drivers/media/video/uvc/uvc_v4l2.c Wed Nov 25 18:02:18 2009 +0530
@@ -194,6 +194,13 @@
if (stream->dev->quirks & UVC_QUIRK_PROBE_EXTRAFIELDS)
probe->dwMaxVideoFrameSize =
stream->ctrl.dwMaxVideoFrameSize;
+ /*
+ * For Bulk transfers, dwMaxPayloadSize is being consider to allocate
+ * URB buffers. But here variable probe is being initialized with "0"
+ * which makes BULK transfer to fail. Hence copying the dwMaxPayloadSi
+ * ze from streaming control variable
+ */
+ probe->dwMaxPayloadTransferSize = stream->ctrl.dwMaxPayloadTransferSize;
/* Probe the device. */
ret = uvc_probe_video(stream, probe);
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
