[Libusb-devel] libusb_claim_interface and SET_INTERFACE

[Xiaofan Chen]

I have some doubts of what libusb_claim_interface

[Xiaofan Chen]

Post by Xiaofan Chen
I have some doubts of what libusb_claim_interface

[kenichi]

I am confused by usb_claim_interface usage.
SET_INTERFACE setup package will not be issued after calling
usb_claim_inteface.

since it orgins from linux kernel. it makes sense that it can't work under
windows.

[Xiaofan Chen]

Post by kenichi
I am confused by usb_claim_interface usage.
SET_INTERFACE setup package will not be issued after calling
usb_claim_inteface.

Under Windows, it is not issued. But I am not so sure about Linux
and I am asking the question whether SET_INTERFACE is issued
or not by Linux libusb (0.1 and 1.0).

Post by kenichi
since it orgins from linux kernel. it makes sense that it
can't work under windows.

The Window implementation of libusb-win32 or the
libusb-1.0 Windows backend are different.

[Alan Stern]

Post by Xiaofan Chen
I have some doubts of what libusb_claim_interface

[Xiaofan Chen]

The code is the same in libusb 0.1.
http://libusb.svn.sourceforge.net/viewvc/libusb/trunk/libusb/linux.c?revision=658&view=markup
Similar question: what does IOCTL_USBFS_RELEASEINTF do?

That ioctl will send a Set-Interface request to switch the interface
back to altsetting 0 if it isn't in altsetting 0 already.  Otherwise it
is similar to CLAIMINTF.

Do you think this is Set-Interface request is necessary?

The documentation for libusb-1.0 is not quite the same as what
you say.

++++++++++++
http://libusb.sourceforge.net/api-1.0/group__dev.html#gaf0d053dd23420c4daec89c06da04abe4

int libusb_release_interface ( libusb_device_handle * dev,
int interface_number
)

Release an interface previously claimed with libusb_claim_interface().

You should release all claimed interfaces before closing a device handle.

This is a blocking function. A SET_INTERFACE control request will
be sent to the device, resetting interface state to the first alternate setting.
++++++++++++

Where are these IOCTL documented for usbfs under Linux?

Those ioctls are implemented in drivers/usb/core/devio.c, using
subroutines from drivers/usb/core/driver.c.  I don't think they are
_explained_ anywhere.  :-)

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=blob;f=drivers/usb/core/driver.c;hb=HEAD
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=blob;f=drivers/usb/core/devio.c;hb=HEAD

I see. Thanks. Interestingly devio.c is quite similar to libusb. ;-)

[Alan Stern]

Post by Xiaofan Chen

The code is the same in libusb 0.1.
http://libusb.svn.sourceforge.net/viewvc/libusb/trunk/libusb/linux.c?revision=658&view=markup
Similar question: what does IOCTL_USBFS_RELEASEINTF do?

That ioctl will send a Set-Interface request to switch the interface
back to altsetting 0 if it isn't in altsetting 0 already.  Otherwise it
is similar to CLAIMINTF.

Do you think this is Set-Interface request is necessary?

Yes. Drivers and programs expect that an interface will be in
altsetting 0 when they first encounter it, so the kernel should arrange
for this to be true.

Also, if a device uses isochronous transfers then the bandwidth
allocated for those transfers might not get released until the
altsetting is changed. (The USB spec helps us there, because
interfaces aren't allowed to use any isochronous bandwidth in
altsetting 0.)

(Actually this isn't quite true. Under Linux, bandwidth currently is
allocated only while a transfer is in progress; however there's a good
chance that in the future we will switch over to allocating bandwidth
as soon as an altsetting is installed. In any case, it's probably best
to put the device in a state where it won't be expecting any
time-critical transfers to take place; this may help reduce power
consumption.)

Post by Xiaofan Chen
The documentation for libusb-1.0 is not quite the same as what
you say.
++++++++++++
http://libusb.sourceforge.net/api-1.0/group__dev.html#gaf0d053dd23420c4daec89c06da04abe4
int libusb_release_interface ( libusb_device_handle * dev,
int interface_number
)
Release an interface previously claimed with libusb_claim_interface().
You should release all claimed interfaces before closing a device handle.
This is a blocking function. A SET_INTERFACE control request will
be sent to the device, resetting interface state to the first alternate setting.
++++++++++++

I'm afraid the libusb documentation is out of date. The Linux kernel
used to behave that way, but it caused problems with too many devices
(their firmwares didn't support multiple altsettings and would crash
upon receiving Set-Interface). So the kernel was changed, a little
under two years ago, to send the Set-Interface request only when it was
needed, that is, only when the interface wasn't already in the first
alternate setting.

Post by Xiaofan Chen

Where are these IOCTL documented for usbfs under Linux?

Those ioctls are implemented in drivers/usb/core/devio.c, using
subroutines from drivers/usb/core/driver.c.  I don't think they are
_explained_ anywhere.  :-)

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=blob;f=drivers/usb/core/driver.c;hb=HEAD
http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.34.y.git;a=blob;f=drivers/usb/core/devio.c;hb=HEAD
I see. Thanks. Interestingly devio.c is quite similar to libusb. ;-)

Naturally, since it does much the same thing: provide a user interface
for controlling USB devices.

Alan Stern

[Tim Roberts]

Post by Alan Stern
(Actually this isn't quite true. Under Linux, bandwidth currently is
allocated only while a transfer is in progress; however there's a good
chance that in the future we will switch over to allocating bandwidth
as soon as an altsetting is installed.

That's interesting, and I hadn't realized this was a difference. So,
this implies that it is possible for me to "overcommit" the bus by, for
example, plugging in 8 web cameras and selecting their max bandwidth
isochronous alternate settings. How would I see the failure? Would it
be the individual URBs failing when the third camera actually starting
issuing transfers?

I guess I don't really see any downside to that approach over the
Windows approach, which signals the failure when the third web camera
selects its alternate setting, with the possible exception that the
Windows approach lets me ratchet down through other alternate settings
until I find one that fits.

[Alan Stern]

Post by Tim Roberts

Post by Alan Stern
(Actually this isn't quite true. Under Linux, bandwidth currently is
allocated only while a transfer is in progress; however there's a good
chance that in the future we will switch over to allocating bandwidth
as soon as an altsetting is installed.

That's interesting, and I hadn't realized this was a difference. So,
this implies that it is possible for me to "overcommit" the bus by, for
example, plugging in 8 web cameras and selecting their max bandwidth
isochronous alternate settings.

That's right.

Post by Tim Roberts
How would I see the failure? Would it
be the individual URBs failing when the third camera actually starting
issuing transfers?

Yes. The URB submissions would fail with a particular error code
(ENOSPC) indicating that they would overcommit on bandwidth.

Post by Tim Roberts
I guess I don't really see any downside to that approach over the
Windows approach, which signals the failure when the third web camera
selects its alternate setting, with the possible exception that the
Windows approach lets me ratchet down through other alternate settings
until I find one that fits.

On the whole, I'm not sure which is better. You find out up front if
the resources are insufficient and you don't have to worry about
bandwidth later on. But you also tie up resources that might have been
useful for something else.

The main motivation for switching over to the Windows approach is
because the USB spec seems to say that's how host software should work.

Alan Stern