Jiri Kosina wrote:
What exactly is the problem here? I didn't seem to catch the beginning of the thread (or it happened off the list I am subscribed to).
Sorry, the current situation is a little confused. Here's a background and summary: My set of applications (ArgyllCMS) needs to access various Serial and USB connected color measuring instruments. Up to now, most of these were labelled as vendor specific, and accessing them via libusb can be made to work satisfactorily. [My applications are cross platform, a major reason for sticking to libusb/libusb-win32 wherever possible.] A couple label themselves as some other class: The HCFR <http://www.homecinema-fr.com/colorimetre/index_en.php> labels itself a communication device. Unfortunately when measuring very dark colors, it has a very long response time (over 30 seconds), and apparently the Linux communication driver times out on the USB transaction. Since the timeouts are something I can control using libusb, driving it via libusb is the simplest workaround, and something I prefer from a cross platform point of view (I'm not sure there if there is any way that the fake communication device can be identified from the actual USB device across all platforms). The Gretag/Pantone Huey <http://www.pantone.com/pages/products/product.aspx?pid=79>, labels itself an HID device. It however doesn't use HID standard messages, but expects the application to be able to compose its own custom messages. On MSWindows and OS X the HID driver allows this, and this is how the manufacturers applications talk the Huey. Unfortunately on Linux, there is no provision for application composed messages, so the Linux HID driver can't be used, and I've used libusb instead. In both of the above cases, there is the issue that the class driver will automatically grab the device, preventing my applications from accessing them via libusb. libusb provides a solution to this, in the form of the usb_detach_kernel_driver_np() call, which is implemented using IOCTL_USB_DISCONNECT (#defined as _IO('U', 22) in the libusb source). This is the approach that libhid uses, since it also builds on top of libusb. At least on the system I've been using for testing (RH4 clone, kernel 2.6.9-55.EL), all this works pretty well, although the exact semantics of using usb_detach_kernel_driver_np() aren't very well documented. I was doing something like: usb_open() usb_set_configuration() for all interfaces { usb_detach_kernel_driver_np(iface) usb_claim_interface(iface) } without a problem. Reports (from Hal V. Engel) though indicated that this doesn't work on other systems. Hal found that the usb_set_configuration() call was failing, and that he had to re-arrange things thus to get it to work: usb_open() usb_detach_kernel_driver_np(0) usb_set_configuration() for all interfaces { usb_claim_interface(iface) } So it seems that the underlying ioctl(IOCTL_USB_SETCONFIG) response is different on his system to mine. I also experienced the same issue with the Huey on a friends system, and the same solution seemed to work. (sorry, I don't have the specifics of these two systems). A recent report (from Frederic Crozat) using the above sequence is that it too doesn't work on some systems (sorry, again I don't have the specifics of the system), and fail at the usb_detach_kernel_driver_np(0) call: open("/dev/bus/usb/002/004", O_RDWR) = 3 ioctl(3, USBDEVFS_IOCTL, 0xbf7e7814) = -1 EINVAL (Invalid argument) ioctl(3, USBDEVFS_SETCONFIGURATION, 0xbf7e7834) = -1 EBUSY (Device or resource busy) When some other people tried the software, they came do a different conclusion: that the Huey wrongly calls itself an HID device, and that it should be put on the exception (quirk) list of the HID kernel driver. I'm not sure I agree with this, since the Huey does work with the HID driver on the two other platforms. Note that the above issues will also occur for the HCFR, since the communication driver needs to be disconnected from it for libusb to work. [On top of the above are various issues related to how the instruments are assigned suitable permissions so that user applications can open them. Various different schemes involving hotplug, udev, PolicyKit have been recommended. The rapid changes in this area have lead to high confusion for end users. As an application writer, this is making Linux a difficult platform to target.] ------------------------------------------------------------ To round out this summary, I'll attach another (relatively unrelated) problem that users of ArgyllCMS are bumping against: One version of the Eye-One Pro instrument (rev D), <http://www.xrite.com/product_overview.aspx?id=790> has a problem when it comes to closing the USB port. On my system if I simply close the port on application exit, then any subsequent attempt to use the device results in: Error - Configuring USB port 'usb:/bus0/dev2 (GretagMacbeth i1 Pro)' to 1 failed with -71 (could not set config 1: Protocol error) and only un-plugging and re-plugging the device restores it to operation. (This doesn't occur on MSWindows or OS X, or using the Rev A instrument. Gretag changed the devices hardware between Rev A and Rev D, and have used a different micro). To work around this issue, I changed the code for this device to do a usb_reset() rather than a usb_close() (ie. this translates to an IOCTL_USB_RESET with is #defined as _IO('U', 20)). This is a little slow, but is the equivalent of un-plugging and re-plugging, and solved the problem. Recent reports (presumably more recent Linux versions) are that this no longer works, not does just closing the port. Attached below is the lsusb -v for this device. Graeme Gill. Bus 003 Device 005: ID 0971:2000 Gretag-Macbeth AG Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0971 Gretag-Macbeth AG idProduct 0x2000 bcdDevice 3.00 iManufacturer 1 GretagMacbeth iProduct 2 eye-one iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 46 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type none Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type none Usage Type Data wMaxPacketSize 0x0040 bytes 64 once bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type none Usage Type Data wMaxPacketSize 0x0020 bytes 32 once bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 3 Transfer Type Interrupt Synch Type none Usage Type Data wMaxPacketSize 0x0008 bytes 8 once bInterval 100 Language IDs: (length=4) 0409 English(US) - To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
