BlackBerry (Re: using libusb)

[Hans Petter Selasky]

On Wednesday 09 January 2008, Mikhail Teterin wrote:
> = I'm trying to port a suit called "barry", which provides a library and
> some = utilities to work with RIM's BlackBerry devices.
>
> = It compiles cleanly, but fails to find a connected device at run time. In
> = fact, it fails to find _any_ devices, even though ``usbdevs -v'' lists
> = several including the BlackBerry
>
> Ok, I see, what's happening... The current implementation of libusb's BSD
> support (bsd.c) ignores all devices other than ``ugen'':
>
>     if (strncmp(di.udi_devnames[0], "ugen", 4) != 0) {
>       /* best not to play with things we don't understand */
>       continue;
>
> And BlackBerry is identified as ``umass'' here :(
>
> Not sure, how best to solve this -- commenting out the above-quoted "if"
> simply leads to a failure later, because the code will look for
> /dev/umassX, which simply would not exist -- umass0 is da3 here. But it
> might be da0 somewhere else, and there is no way to know, which is which
> :-(
>
> But even if one could figure this out and specify the device to the tool
> explicitly, daX will not understand ugen's ioctls anyway...
>
> What a retarded mess...
>
> We really need the low-level (ugen?) interfaces available for all
> USB-devices -- even those, which are /also/ handled by higher-level
> interfaces (like ulpt, uscan, umass). As things stand, the higher-level
> ones are "greedy" and will prevent ugen from appearing, even if one wanted
> to.

Hi Mikhail,

Yes, you are completely right. And this is not very far away from happening. 
I've wanted to do this for a long time, but have found no time yet.

My plan is to extend /dev/usbX so that it becomes a so-called clonable device. 
When you open up "/dev/usb0.2.3" for example, you open up the device having 
index 2 on USB bus 0 and endpoint 3. This will need some modifications in 
libusb. Ugen will still be there, but I plan to move the functionality over 
to "usb.c". Accessing endpoints will then work regardless of what drivers are 
hooked on.

Some open problems that needs to be resolved:

Should we allow parallell access to USB interfaces?

And what about rights management?

>
> Hans, any hope? Thank you!
>

In the end of the tunnel :-)

--HPS