Re: [Bitpim-devel] libusb / Darwin

[Steven P. <n9...@n9...>]

On Dec 16, 2003, at 12:22 AM, Roger Binns wrote:
> You have two choices as to how to handle USB integration.  One is
> to get libusb working with its current semantics, making tweaks
> as appropriate providing they work on all platforms.
>
> The other choice is a completely seperate usbmac.py file that
> provides the same external API but the internals are different.
> I can make the import process use the correct usb.py/usbmac.py
> file depending on platform.

  There may yet have to be a third choice. The issue is that once a 
device is spoken for by a kernel driver, you can not get access to it 
to configure it. And in order for the phone to function as a network 
interface via PPP, you have to have the kernel driver loaded, so this 
is like to be a problem.

  The workaround on the Mac is essentially to bypass the open device, 
configure, claim interface stuff and maybe jump right to opening the 
requisite interface on the device. I have done some more reading on 
this, and I should be able to find the device, enumerate it's 
interfaces, get vendor/product/protocol information, device descriptor, 
etc... even if it's claimed by a kernel driver, but I can not open the 
device itself, only it's unclaimed interface(s). This is where the 
libusb model breaks down. However, I perhaps can add an additional bit 
to libusb such as open_usb_interface() as a fallthrough in case opening 
the device fails.

  If I added some extra routines to scan the Mac USB bus much like you 
scan the Windows registry in comscan, we could get a list of devices 
and their information for sorting/sifting by comdiagnose.  This is 
probably necessary to get the "auto" port stuff to work anyway, and 
isn't directly related to the issue at hand other than providing a way 
to find the USB device information.

  So, if we have a USB device the kernel (or other driver) has not 
claimed, we can use libusb as it is. However, even if the device itself 
is busy we might be able to get the the interface we need. I don't know 
if you have this capability in Windows or Linux, but this approach 
would almost require saying something like... "If the device is there, 
but busy, and we know which interface we need (or can sort/sift based 
on returned interface information), try to open the interface itself 
directly without regard to the device node."

  If this type of operation is possible on Windows/Linux, we could make 
it an alternate fallback approach if the main device is busy. 
Otherwise, I suppose we could just make this fallback approach 
available on the Mac. The user wouldn't have to do anything different, 
it would all be handled by code.

  Forgive me again if there is rambling and random thoughts here, I'm 
thinking this through and trying to keep this platform consistent. The 
problem here is that all three systems have peculiarities and it's hard 
to try to find a platform independent paradigm and make all of them fit 
into that mold. It's even harder to take a specific platform, say what 
works for Windows, and then try to shoehorn the others to fit that 
mode. Maybe. :-)

-. ----. -.-- - -.--
Steve Palm - n9...@n9...
-. ----. -.-- - -.--