Re: [libusb] #165: Darwin: submit_iso_transfer() assumes HS device.

[Nathan H. <hj...@me...>]

On Mar 27, 2013, at 11:16 PM, Xiaofan Chen <xia...@gm...> wrote:

> On Thu, Mar 28, 2013 at 8:10 AM, libusb Trac <tr...@li...> wrote:
>> #165: Darwin: submit_iso_transfer() assumes HS device.
>> ---------------------+---------------------------------------
>>  Reporter:  zyp     |      Owner:  hjelmn
>>      Type:  defect  |     Status:  assigned
>> Milestone:  1.0.16  |  Component:  libusb-1.0 Darwin backend
>> Resolution:          |   Keywords:
>> Blocked By:          |     Blocks:
>> ---------------------+---------------------------------------
>> 
>> Comment (by hjelmn):
>> 
>> So maybe something like:
>> 
>> cInterface->frames[transfer->endpoint] = frame + transfer->num_iso_packets
>> * (1 << (bInterval-1)) / 8;
>> 
>> Since the interval is 2^(bInterval-1) * 125 us. Does that sound right?
> 
> Looks right.
> 
> I am still wondering why the Darwin backend needs to do such low
> level stuff on the isochronous transfer.

Not sure. The isoch transfer functions need a start frame to complete successfully. The current implementation uses the larger of the current frame number + 4 or the frame after the last frame used by the last isochronous transfer on the endpoint.

> It is said that there are high speed device with quirks since they use
> full speed bInterval values. So for this kind of device, the above
> codes will have issues. No so sure how to deal with them. I assume
> the Linux backend will be okay since the kernel will deal with the
> quirks and libusb's usbfs backend will not be affected and I do not
> see any such low level codes in the Linux backend anyway.
> 
> http://www.lvr.com/usbfaq.htm
> "Reports are that some device providers are using full-speed bInterval
> values in high-speed descriptors. Reports also say that under Windows,
> a device may receive its intended polling rate (rather than its requested
> polling rate) in spite of this error. Other operating systems are likely to
> attempt to provide the requested polling rate, or may report an illegal
> bInterval value."
> 
> I do not know about the situation under Mac OS X, at least under
> Linux, there are kernel quirks to deal with such device. The following
> patch is about high speed interrupt endpoint, but there are
> probably similar things for isochronous endpoint as well.
> 
> Eg: http://www.spinics.net/lists/linux-usb-devel/msg07329.html
> +	/* Fix up bInterval values outside the legal range. Use 32 ms if no
> +	 * proper value can be guessed. */
> 	i = 0;		/* i = min, j = max, n = default */
> 	j = 255;
> 	if (usb_endpoint_xfer_int(d)) {
> 		i = 1;
> 		switch (to_usb_device(ddev)->speed) {
> 		case USB_SPEED_HIGH:
> -			n = 9;		/* 32 ms = 2^(9-1) uframes */
> +			/* Many device manufacturers are using full-speed
> +			 * bInterval values in high-speed interrupt endpoint
> +			 * descriptors. Try to fix those and fall back to a
> +			 * 32 ms default value otherwise. */
> +			n = fls(d->bInterval*8);
> +			if (n == 0)
> +				n = 9;	/* 32 ms = 2^(9-1) uframes */
> 			j = 16;
> 			break;
> 		default:		/* USB_SPEED_FULL or _LOW */
> 
> 
> It is true for isochronous endpoint as well.
> Ref: http://www.ideasonboard.org/uvc/faq/
> UVC_QUIRK_STATUS_INTERVAL	0x00000001	
> Interpret the status endpoint bInterval value as a number of frame
> instead of an exponent value.

If I read this correctly the only issue is if bInterval = 0. Is that correct. Seems like an easy special case to handle. I will write a patch in the next couple of days and post it to the ticket.

-Nathan