Thanks, I've finally got it. I see that my incorrect terminology has not helped. Sorry to have made you re-iterate couple of points there.
1) usbfs can indeed be bound to the interface on the device but the act of binding has to be performed by ioctl's ( in this case the ones generated by libusb ) 2) You cannot build the "interface > usbfs > libusb > program" chain consecutively step by step from the bottom up. Instead the program asks libusb to generate ioctl's which will bind the device's interface to usbfs. ie a "from the top down" approach 3) It looks like there are no usb errors occurring between my device and the system, but rather there is a device-specific error between my device and it's program. ie the usb part is fine 4) The other way that the vendor could have accomplished the above would have been to have a "driver" which has it's own /sys/bus/usb/driver/my_driver directory. This driver would identify connected interaces which it supports and would use ioctl's to bind the device's interface to it's /sys/bus/usb/my_driver point. Programs would then make calls to the driver to get "stuff" done Thanks Alan and Greg for all of your help. Having a look at the archives I can see that this falls far below the scope of your normal technical correspondence so I am sincerely thankful that you have taken the time to help me. Hopefully in around 5 years I will be able to contribute some linux drivers myself : ) Cheers Nick On Mon, 4 Feb 2008 16:42:29 -0500 (EST), Alan Stern <[EMAIL PROTECTED]> wrote: > 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
