On Tue, 5 Feb 2008 [EMAIL PROTECTED] wrote: > Sorry guys, thanks for your perseverance so far : ) > > Greg: where you wrote: > > In order for a device to bind successfully with a driver, that > > driver must already support that device. This is why you can not > > just arbitrarily bind any device to any driver. > It sounds like a chicken or the egg type scenario to me where libusb cannot > access the device to support it until it is bound to usbfs but you can't > bind it to usbfs unless it is supported ?
You're not using the right words, probably because you're not thinking about this the right way. A binding is a connection between a device (or in the case of USB, an interface) and a driver. usbfs is sort of a driver, so it can bind to interfaces. But libusb isn't a driver and it can't bind to anything. Instead it uses usbfs to do its work. A driver can bind to an interface only if it supports that interface. This isn't an issue with usbfs, since usbfs supports all interfaces. > I am keen to solve my problem but I am also very keen to gain knowledge on > how the whole system hangs together. Can someone describe the chain of > events where libusb is concerned, my thought pattern was along the line of: > You could manually bind anything whatsoever to /sys/bus/usb/drivers/usbfs, > it is simply a portal which exposes resources to the next level up. You do not manually bind things to /sys/bus/usb/drivers/usbfs. Instead the binding happens automatically when a program uses the USBFS_CLAIMINTERFACE ioctl. As you have discovered, usbfs doesn't support manual binding. > You > could then use libusb to access any of the device's resources without > having to use ioctl() calls etc. Your actual program then talks to libusb > to get things done. Correct -- libusb issues the ioctl calls for your program. In particular, it issues the CLAIMINTERFACE ioctl on your program's behalf when your program calls usb_claim_interface(). > Alan: Here is what happens the first time and second time ( as they seem to > differ ) that I run the binary that controls the device ( Velleman k8055 > usb io board ) > > [EMAIL PROTECTED] ~]# k8055 -p:3 > Velleman Device Found @ Address 002 Vendor 0x010cf Product ID 0x05503 > Got driver name: usbhid > Disconnected OS driver: No error This means that the usbhid driver had previously been bound to your interface. The program used the usb_detach_kernel_driver_np() routine (which sends usbfs a USBDEVFS_DISCONNECT ioctl) to unbind usbhid. > Found interface 0 > Took over the device Then presumably the program caused usbfs to bind to the interface. > Read retry > Read retry > Read retry > Write retry > Read retry > Read retry > Read retry > Write retry > Read retry > Read retry > Read retry > Write retry > Could not open the k8055 (port:3) > Please ensure that the device is correctly connected. But something went wrong when the program tried to communicate with the device. > [EMAIL PROTECTED] ~]# k8055 -p:3 > Velleman Device Found @ Address 002 Vendor 0x010cf Product ID 0x05503 > get driver name: could not get bound driver: No data available This time there was no driver previously bound to the interface, so nothing needed to be unbound. > Found interface 0 > Took over the device > Read retry > Read retry > Read retry > Write retry > Read retry > Read retry > Read retry > Write retry > Read retry > Read retry > Read retry > Write retry > Could not open the k8055 (port:3) > Please ensure that the device is correctly connected. But again the communication failed. To get more information about what's going wrong, you can set the usbfs_snoop=y module parameter for usbcore. Most usbfs activities will then show up in the dmesg log. Alan Stern - 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
