Hi Laurent,
Anything on this front?
Regards,
Ramesh.
On Wed, Nov 25, 2009 at 6:19 PM, Ramesh Rajagopal <shm...@gmail.com> wrote:
> 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.
>>
>>
>>
>
_______________________________________________
Linux-uvc-devel mailing list
Linux-uvc-devel@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
