Re: [Bitpim-devel] libusb

[Roger B. <ro...@ro...>]

>   What a shame, then, that MacOS X sort of gets in the way of this.
> Well, perhaps not, because if you can't use the device then what is the
> point of allowing it to show up?  

The code is in two pieces.  One piece (comscan and usbscan) finds all
devices.  The second piece (comdiagnose) then makes an intelligent
decision about which of the devices are likely to be the phone, and
prioritises them.

At the moment comdiagnose has the USB ids in its code.  That information
will be moving to the profile class for each phone.

> In this case, I mean the other
> interfaces which are already spoken for by the kernel drivers... I am
> able to get a list of the busses and vendor/products of the devices on
> the bus, I just can't open the device if it's busy. I suppose I could
> *try* to open a whole range of interfaces on the device, say, 0-32, and
> save a list of the ones that could be opened.

comscan and usbscan do include information about whether the particular
port/device is available.  There are both 'active' and 'available'
flags.  'active' would be false if the driver etc existed but the cable/
device was unplugged.  'available' means bitpim could use it.
The simple test in comscan is to try to open the device, and something
similar is done in usb scan.

>   Well, USB-to-serial cables would be mapped (at least on MacOS X) to
> /dev/cu.* devices (most likely), and then could be handled outside of
> the USB stuff.

And under Windows they are mapped to COM ports, and under Linux to
/dev/usb/ttyUSB0..

However the USB information is still useful.  For example under Windows
the USB to serial cable has a hardwareinstance value of
...&VID_1234&PID_1234

That is how I can tell that particular com port is a USB to serial 
cable (and hence could have a phone on the end) as opposed to a motherboard
serial port which definitely doesn't have a phone on it.

>>>   On MacOS X for this device, you *CAN* get to the interface in
>>> question, but you actually have to go directly for the interface by
>>> vendor, product, configuration and interface number.

The good news is that almost every device in existence only has 1
configuration and the configuration value is 1.

> I see you have some
> USB->serial cables there with no interface listed. Do these connect as
> USB or through a device entry?

They are connected through the Windows COM port name, not directly via
libusb.  As mentioned above, I can use the usb ids to figure out what
the com port actually is.

>   At any rate, I will play around with a few things and get back to you.
> Unless I get it working at all, there's not much point in haggling over
> how to fit it into the project. :-)

Yup.  Get some horrible disgusting hack working and then take it from
there :-)

Roger