USBDEVFS_URB_TYPE_INTERRUPT

USBDEVFS_URB_TYPE_INTERRUPT

[John Chris Wren]

	I was designing a USB based device and was looking through the 2.4.5 kernel
code, and noticed that while it supports bulk, iso, and control types, there
is no support for interrupt types.  A grep through the entire kernel source
code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in
linux/usbdevice_fs.h, but no where is it used.  Any thoughts as to why that
might be?

	A google search didn't seem to turn up any answers either.

	-- John

Re: USBDEVFS_URB_TYPE_INTERRUPT

[Greg KH]

On Wed, Jun 06, 2001 at 01:31:41AM -0400, John Chris Wren wrote:
> 
> 	I was designing a USB based device and was looking through the 2.4.5 kernel
> code, and noticed that while it supports bulk, iso, and control types, there
> is no support for interrupt types.  A grep through the entire kernel source
> code reveals that USBDEVFS_URB_TYPE_INTERRUPT defined in
> linux/usbdevice_fs.h, but no where is it used.  Any thoughts as to why that
> might be?
> 
> 	A google search didn't seem to turn up any answers either.

Try this thread for why it is not supported:

	http://marc.theaimsgroup.com/?l=linux-usb-devel&m=99004006207974&w=2

If you still have questions about this, the linux-usb-devel mailing list
is the better place to discuss it.

greg k-h

Re: USBDEVFS_URB_TYPE_INTERRUPT

[John Chris Wren]

	Sigh.  What do half the answers always show up seconds after clicking
'Send'?

	I see there is a FILL_URB_INT macro in linux/usb.h, but the only things
using it seem to be drivers (as opposed to usbstress, libusb, etc).  The
ioctl call supports USBDEVFS_SUBMITURB, but passing a type
USBDEVFS_URB_TYPE_INTERRUPT returns EINVAL.  If the ioctl calls are the
'proper' way to talk to the USB drivers, should my code be calling
usb_submit_urb directly if I want to pass interrupt type messages?

	I don't really want to write a full-up kernel mode driver for this device,
but interrupt type messages are the preferred method for communicating,
since once a message needs to be sent, it should be timely (whereas control
messages could be delayed a significant amount on a busy USB channel).

	-- John

Re: USBDEVFS_URB_TYPE_INTERRUPT

[Thomas Sailer]

John Chris Wren schrieb:

>         I don't really want to write a full-up kernel mode driver for this device,
> but interrupt type messages are the preferred method for communicating,
> since once a message needs to be sent, it should be timely (whereas control
> messages could be delayed a significant amount on a busy USB channel).

If you critically depend on tight timing you'll need a kernel driver
anyway, as your usermode task might be delayed on a busy machine too.
Otherwise you can use bulk ins timed from userspace

Tom