Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1598811 > unrolled thread

Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk Dave Mielke <dave@mielke.cc> - 2017-03-13 02:50 +0100
    Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk Dave Mielke <dave@mielke.cc> - 2017-03-13 11:40 +0100
    Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk Alan Stern <stern@rowland.harvard.edu> - 2017-03-14 02:50 +0100
      Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk Dave Mielke <dave@mielke.cc> - 2017-03-14 03:30 +0100
        Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk Samuel Thibault <samuel.thibault@ens-lyon.org> - 2017-03-14 09:50 +0100

#1598811 — Re: [PATCH] usb-core: Add MS_INTR_BINTERVAL USB quirk

[quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400]

>No, I was wondering why an HID device would run at high speed.  Both
>you and Samuel implied that this was because it was a USB-2 device.  
>But that is not an adequate answer, because it is perfectly valid for a 
>USB-2 device to run at full speed.

What should we look at to find out what speed it wants to operate at? We didn't 
look into it becuaase the real problem, from our perspective, was that the 64ms 
interval was being honoured by the host when it should be the 10ms as is 
literally in the endpoint descriptor. Our assumption was that since it says 
it's USB 2.0 then bInterval must be intterpreted in light of that regardless of 
the actual speed used for communication.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave@Mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/

[toc] | [next] | [standalone]

#1599185

[quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400]

>No, I was wondering why an HID device would run at high speed.  Both
>you and Samuel implied that this was because it was a USB-2 device.  
>But that is not an adequate answer, because it is perfectly valid for a 
>USB-2 device to run at full speed.

I think I've misunderstood something about how to interpret bInterval. I'm now 
suspecting that bInterval must be interpreted the new (mocro frame) way only if 
the device is operating at least at high speed, and that, even if the device 
advertizes itself as USB 2.0, bInterval must still be interpreted the old way 
if the device is operating at full or low speed. Is that correct?

If the above is correct, how can we tell from usbfs which way to interpret 
bInterval?

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave@Mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/

[toc] | [prev] | [next] | [standalone]

#1599978

On Sun, 12 Mar 2017, Dave Mielke wrote:

> [quoted lines by Alan Stern on 2017/03/12 at 21:40 -0400]
> 
> >No, I was wondering why an HID device would run at high speed.  Both
> >you and Samuel implied that this was because it was a USB-2 device.  
> >But that is not an adequate answer, because it is perfectly valid for a 
> >USB-2 device to run at full speed.
> 
> What should we look at to find out what speed it wants to operate at? We didn't 

The speed is reported in the kernel log and in 
/sys/kernel/debug/usb/devices.

> look into it becuaase the real problem, from our perspective, was that the 64ms 
> interval was being honoured by the host when it should be the 10ms as is 
> literally in the endpoint descriptor. Our assumption was that since it says 
> it's USB 2.0 then bInterval must be intterpreted in light of that regardless of 
> the actual speed used for communication.

You should read the USB specification.  Specifically, table 9-13 in 
section 9.6.6 describes bInterval like this (in part):

	Interval for polling endpoint for data transfers.
	Expressed in frames or microframes depending on the
	device operating speed (i.e., either 1 millisecond or
	125 μs units).

	For full-/high-speed isochronous endpoints, this value
	must be in the range from 1 to 16. The bInterval value
	is used as the exponent for a 2^(bInterval-1) value; e.g., a
	bInterval of 4 means a period of 8 (2^(4-1)).

	For full-/low-speed interrupt endpoints, the value of
	this field may be from 1 to 255.

	For high-speed interrupt endpoints, the bInterval value
	is used as the exponent for a 2^(bInterval-1) value; e.g., a
	bInterval of 4 means a period of 8 (2^(4-1)). This value
	must be from 1 to 16.

> Yes, I did know this, so maybe I misunderstood what you were wondering about.
> Were you wondering why 64ms was too long?

No.  I was wondering why an HID device would run at high speed.

> I think I've misunderstood something about how to interpret bInterval. I'm now 
> suspecting that bInterval must be interpreted the new (mocro frame) way only if 
> the device is operating at least at high speed, and that, even if the device 
> advertizes itself as USB 2.0, bInterval must still be interpreted the old way 
> if the device is operating at full or low speed. Is that correct?

Like I said, read the spec.

> If the above is correct, how can we tell from usbfs which way to 
> interpret bInterval?

There is an ioctl you can use to find the device speed: 
USBDEVFS_CONNECTINFO.  Unfortunately, this ioctl is badly out of date 
and only distinguishes between low speed and non-low speed.  A patch to 
remedy this situation would be welcome.

However, in general, users of usbfs don't need to know the device
speed.  In particular, you don't need to interpret bInterval.  Just
submit URBs quickly enough that the pipeline never empties out.

Alan Stern

[toc] | [prev] | [next] | [standalone]

#1599996

Thank you for your very helpful answer. I really do appreciate it.

It's possible that this device is using high speed because it offers a feature 
to transfer its internal clipboard to the host, and it allows that clipboard to 
contain lots of data. Interestingly, though, hidden within a usage note, they 
do observe that, so far, they've been unable to achieve a transfer speed faster 
than 5,000 characters in seven minutes. It looks to me like this is exactly due 
to their incorrect setting of bInterval. :-) I've sent them a note about it.

-- 
Dave Mielke           | 2213 Fox Crescent | The Bible is the very Word of God.
Phone: 1-613-726-0014 | Ottawa, Ontario   | http://Mielke.cc/bible/
EMail: Dave@Mielke.cc | Canada  K2A 1H7   | http://FamilyRadio.org/

[toc] | [prev] | [next] | [standalone]

#1600125

Dave Mielke, on lun. 13 mars 2017 22:20:01 -0400, wrote:
> It's possible that this device is using high speed because it offers a feature 
> to transfer its internal clipboard to the host, and it allows that clipboard to 
> contain lots of data. Interestingly, though, hidden within a usage note, they 
> do observe that, so far, they've been unable to achieve a transfer speed faster 
> than 5,000 characters in seven minutes. It looks to me like this is exactly due 
> to their incorrect setting of bInterval. :-) 

Well, still, with a 10ms interval, one can achieve at best 100 key
press events per second, thus 50 characters per second, i.e. not even
1200bps...

Samuel

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web