[Bitpim-devel] libusb / Darwin

[Steven Palm]

Hi Roger,

I am still working on the libusb issue... I thought I'd see if you had
any insight on this one.

Here is what I get as a dump from `python usb.py` (relevant section to
the VX6000 only):

usb_os_open: 0410:0060
usb_os_open: device opened
usb_control_msg: 128 6 512 0 0xbffff568 8 1000
usb_control_msg: 128 6 512 0 0x510e60 90 1000
skipped 4 class/vendor specific interface descriptors
usb_os_close: 0410:0060

I've managed to stop the system (for now) from loading it's own device
driver on the port, and therefore allowing libusb to access it.
Eventually, I will want to have the workaround in place so both can
co-exist, but for troubleshooting this may be easier.

I'm just perplexed as to why libusb is skipping the interfaces on the
device. Here is a dump from libusb's `testlibusb` application:

059/002 0410/0060
- Unable to fetch manufacturer string
- Unable to fetch product string
wTotalLength: 90
bNumInterfaces: 3
bConfigurationValue: 1
iConfiguration: 0
bmAttributes: e0h
MaxPower: 50
bInterfaceNumber: 0
bAlternateSetting: 0
bNumEndpoints: 1
bInterfaceClass: 2
bInterfaceSubClass: 2
bInterfaceProtocol: 1
iInterface: 0
bEndpointAddress: 81h
bmAttributes: 03h
wMaxPacketSize: 16
bInterval: 32
bRefresh: 0
bSynchAddress: 0
bInterfaceNumber: 1
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 10
bInterfaceSubClass: 0
bInterfaceProtocol: 0
iInterface: 4
bEndpointAddress: 8ah
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 0bh
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bInterfaceNumber: 2
bAlternateSetting: 0
bNumEndpoints: 2
bInterfaceClass: 255
bInterfaceSubClass: 255
bInterfaceProtocol: 0
iInterface: 0
bEndpointAddress: 83h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0
bEndpointAddress: 06h
bmAttributes: 02h
wMaxPacketSize: 64
bInterval: 0
bRefresh: 0
bSynchAddress: 0

Does this look normal to you, or is something not quite right in the
base darwin libusb stuff?

Thanks,

Steve

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Roger Binns]

Post by Steven Palm
usb_os_open: 0410:0060
059/002 0410/0060

It is having byte ordering issues. Those should be 1004 and 6000.

Post by Steven Palm
- Unable to fetch manufacturer string
- Unable to fetch product string

That is normal.

Post by Steven Palm
bEndpointAddress: 81h
bEndpointAddress: 8ah
bEndpointAddress: 0bh
bEndpointAddress: 83h
bEndpointAddress: 06h

Those endpoints are correct and in the right order. (The 0x80 mask
means they are IN endpoints. The IN and OUT are relative to the
host computer - ie IN is into the host).

Here is Linux lsusb output which is very similar to testlibusb.

Bus 001 Device 021: ID 1004:6000
cannot get string descriptor 1, error = Connection timed out(110)
cannot get string descriptor 2, error = Connection timed out(110)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.01
bDeviceClass 2 Communications
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 16
idVendor 0x1004
idProduct 0x6000
bcdDevice 0.00
iManufacturer 1
iProduct 2
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 90
bNumInterfaces 3
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 2 Communications
bInterfaceSubClass 2 Abstract (modem)
bInterfaceProtocol 1 AT-commands
iInterface 0
unknown descriptor type: 05 24 00 09 01
unknown descriptor type: 05 24 01 03 01
unknown descriptor type: 04 24 02 0f
unknown descriptor type: 05 24 06 00 01
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type none
wMaxPacketSize 16
bInterval 32
cannot get string descriptor 4, error = Connection timed out(110)
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 10 Data
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x8a EP 10 IN
bmAttributes 2
Transfer Type Bulk
Synch Type none
wMaxPacketSize 64
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x0b EP 11 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type none
wMaxPacketSize 64
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type none
wMaxPacketSize 64
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type none
wMaxPacketSize 64
bInterval 0
Language IDs: (length=4)
0409 English(US)

Roger

[Steven Palm]

Post by Roger Binns

Post by Steven Palm
usb_os_open: 0410:0060
059/002 0410/0060

It is having byte ordering issues. Those should be 1004 and 6000.

Well, yes and now... The Mac is big endian, and it's using a format of
%04X to print it out, so I think it's really just a visual thing.
Anyway, it turns out that what I thought was a problem is not
apparently a problem.

I have made the first successful connect to the phone through the USB
interface. I had to do just a few things to make this work here at this
point, and it's not user friendly.

in the _openusb() method of commport.py, I had to insert the following
call:

usb.UpdateLists()

I put it right before it started walking through the bus/dev/iface
tree. For some reason, it seems as though this was not populated and
therefore it always failed to find the phone.

Also, in __init__ of the USBDevice class, I had to remove the
following lines:

if self.handle is None:
raise USBException()

As you walk through the device tree on MacOS, you *will* likely
encounter devices you could not get information about because they are
being used exclusively used by something else.

This allows things to work. I know you are reworking the VX6000
directory stuff, so many of the other issues I am seeing are probably
due to your work in progress. Here is my status:

Specify the device as USB::059:002:2.

* I can import the VX6000 phonebook information into bitpim fine.

* I get an exception when importing calendar information.

Traceback (most recent call last):
File "/Users/n9yty/my_cvs/bitpim/bitpim/gui.py", line 147, in run
res=call()
File "/Users/n9yty/my_cvs/bitpim/bitpim/gui.py", line 88, in __call__
return apply(self.method, self.args+args, d)
File "/Users/n9yty/my_cvs/bitpim/bitpim/gui.py", line 1020, in getdata
i[1](results)
File "/Users/n9yty/my_cvs/bitpim/bitpim/com_lgvx4400.py", line 291,
in getcalendar
sc.readfrombuffer(buf)
File "/Users/n9yty/my_cvs/bitpim/bitpim/p_lgvx4400.py", line 2094, in
readfrombuffer
self.__field_events.readfrombuffer(buf)
File "/Users/n9yty/my_cvs/bitpim/bitpim/prototypes.py", line 578, in
readfrombuffer
x.readfrombuffer(buf)
File "/Users/n9yty/my_cvs/bitpim/bitpim/p_lgvx4400.py", line 1855, in
readfrombuffer
self.__field_description.readfrombuffer(buf)
File "/Users/n9yty/my_cvs/bitpim/bitpim/prototypes.py", line 327, in
readfrombuffer
raise NotTerminatedException()
NotTerminatedException: The value should have been terminated and
wasn't

* When trying to import wallpaper into bitpim, I get a segfault:

#0 0xffff8acc in __memcpy (__memcpy + 812)
#1 0x0307cfdc in wxBaseArrayLong::RemoveAt(unsigned long, unsigned
long) (wxBaseArrayLong::RemoveAt(unsigned long, unsigned long) + 88)
#2 0x0304c968 in wxMutexInternal::Unlock()
(wxMutexInternal::Unlock() + 160)
#3 0x012d992c in wxPyBeginAllowThreads() (wxPyBeginAllowThreads() +
28)
#4 0x013736d4 in _wrap_wxGauge_SetRange (_wrap_wxGauge_SetRange +
204)
#5 0x95f4a8d0 in 0x95f4a8d0
#6 0x95fa9df0 in 0x95fa9df0
#7 0x95fa6d44 in 0x95fa6d44

I realized that I had protocol logging turned on, and when I turned it
off I no longer get the segfault. However, despite a "completion" of
the import, nothing shows up in bitpim for wallpapers.

* When trying to import ringtones into bitpim, no errors, but no data
visible in bitpim.

I do see this in the term window I started bitpim from:

wallpapers present - updating disk
no file for Beach Ball
no file for Towerbridge
no file for Sunflower
no file for Beach
no file for Fish
no file for Sea
no file for Snowman
no file for pic00.jpg
no file for pic01.jpg
no file for pic02.jpg
no file for pic03.jpg
no file for pic04.jpg
no file for bear_heart.bmp
no file for elvis_birthday_sm.jpg
no file for hi_pig_sm.jpg
no file for love_you_cat_sm.jpg
no file for martini.bmp
no file for party_time_sm.jpg
no file for roses.bmp
no file for sorry_monster_sm.jpg
no file for sun.bmp
no file for surfing.bmp
ringtone present - updating disk
Saving phonebook
Saving wallpaper information

So, very good news, communication works, it now has to be
streamlined/etc to make a good user experience.

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Roger Binns]

Post by Steven Palm
* I can import the VX6000 phonebook information into bitpim fine.
* I get an exception when importing calendar information.
NotTerminatedException: The value should have been terminated and
wasn't

The 4400/6000 can never make their minds up if a string is always
NULL terminated. I usually found that it was always null terminated
if entered on the phone, and not if you used other software to
enter the details. Anyway I have now committed a fix so that
exceptions won't be raised if the description field is not null
terminated.

Post by Steven Palm
#0 0xffff8acc in __memcpy (__memcpy + 812)
#1 0x0307cfdc in wxBaseArrayLong::RemoveAt(unsigned long, unsigned
long) (wxBaseArrayLong::RemoveAt(unsigned long, unsigned long) + 88)
#2 0x0304c968 in wxMutexInternal::Unlock()
(wxMutexInternal::Unlock() + 160)
#3 0x012d992c in wxPyBeginAllowThreads() (wxPyBeginAllowThreads() +
28)
#4 0x013736d4 in _wrap_wxGauge_SetRange (_wrap_wxGauge_SetRange +
204)
#5 0x95f4a8d0 in 0x95f4a8d0
#6 0x95fa9df0 in 0x95fa9df0
#7 0x95fa6d44 in 0x95fa6d44

I have no idea what that is about. The gauge is in the status bar
at the bottom.

Post by Steven Palm
However, despite a "completion" of
the import, nothing shows up in bitpim for wallpapers.

I am still working on the new code (the damn 6000 has 4 different locations
to get the wallpaper on so new code code to be written). I haven't
looked into too deeply why yet, but if you import them twice it usually
works. Also on Windows and Linux you have to resize the main window
otherwise they aren't drawn. Again I haven't looked too deeply to
see why.

Post by Steven Palm
* When trying to import ringtones into bitpim, no errors, but no data
visible in bitpim.

The ringtone code is disabled. It will be using the new wallpaper code
since they work in almost exactly the same way.

Roger

[Steven Palm]

Post by Roger Binns

Post by Steven Palm
* I get an exception when importing calendar information.
NotTerminatedException: The value should have been terminated and
wasn't

The 4400/6000 can never make their minds up if a string is always
NULL terminated. I usually found that it was always null terminated
if entered on the phone, and not if you used other software to
enter the details. Anyway I have now committed a fix so that
exceptions won't be raised if the description field is not null
terminated.

At least this set of data was all entered on the phone. If you can
deal with it both ways, I think it's best to make the software tolerate
it.

Post by Roger Binns
I have no idea what that is about. The gauge is in the status bar
at the bottom.

Again, this only happened if I had the protocol log running.
Strange... Maybe it's some internal timing issue or threading conflict.

Post by Roger Binns

Post by Steven Palm
However, despite a "completion" of
the import, nothing shows up in bitpim for wallpapers.

I am still working on the new code (the damn 6000 has 4 different locations
to get the wallpaper on so new code code to be written). I haven't
looked into too deeply why yet, but if you import them twice it usually
works. Also on Windows and Linux you have to resize the main window
otherwise they aren't drawn. Again I haven't looked too deeply to
see why.

I knew you were busy on this code, so I was reporting only as a "this
is where things are here", not as a serious bug report. It's looking
good, though. I found that doing two imports back-to-back got the
wallpaper in the system, and I did have to resize the main window to
draw them.

Post by Roger Binns
The ringtone code is disabled. It will be using the new wallpaper code
since they work in almost exactly the same way.

Ah. :-) That explains it.

Now, time for me to give some thought to how to attack the libusb
issue.... Currently the way I have things working is to disable the
MacOS driver. This means you have no serial interface on
/dev/cu.usbmodemXXX. This means you cannot use the phone for network
PPP connections/etc... Probably not a good thing.

I can get (I believe) a connection to the device with the MacOS driver
loaded, but only as a "interface" connection, I can not connect to or
touch the device. This would require quite a bit of change, from an
initial overview, of how things are handled. In fact, since you connect
by specifying the vendor/product/interface information, it might even
have to be an alternate port specification for the Mac in addition to
usb::. I don't know.... I have to think it through, and get a test
implementation of the interface-only connection working.

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Roger Binns]

Post by Steven Palm
At least this set of data was all entered on the phone. If you can
deal with it both ways, I think it's best to make the software tolerate
it.

Yup, that is why the raiseonunterminated flag exists. However I prefer
being rigorous on expectations of data to and from the phone until
shown otherwise. If you are too lax, it is easy for bugs to get through
and bugs could lead to data corruption.

Post by Steven Palm

Post by Roger Binns
I have no idea what that is about. The gauge is in the status bar
at the bottom.

Again, this only happened if I had the protocol log running.
Strange... Maybe it's some internal timing issue or threading conflict.

It would probably be quite hard to make a simple test case out
of which makes bug reporting it quite hard.

Post by Steven Palm
and I did have to resize the main window to draw them.

I need to figure that one out. Some of the widgets are quite temperamental
but magically behave well when resized.

Did you try writing back? I managed to fill my phone with 70
images. At the moment it doesn't do anything to the camera stuff
when writing back. I'll probably leave it that way, since people
are unlikely to want to upload camera stuff. (The download works
fine),

Post by Steven Palm
In fact, since you connect
by specifying the vendor/product/interface information,

Only the sample code at the bottom of usb.py does that. BitPim
itself calls usbscan.py to get a list of all devices and interfaces.
They are all uniquely named.

If you typed in an explicit name of the port, then _openusb in commport.py
finds that name and opens the endpoint.

If you browse the ports, then usbscan and comscan have their output joined
and comdiagnose produces some html describing each field in each port.

If you select 'auto' as the port, then usbscan and comscan have their
output joined, and comdiagnose picks out and prioritises which are
likely to be the phone.

Roger

[Roger Binns]

Post by Steven Palm

Post by Roger Binns
It is having byte ordering issues. Those should be 1004 and 6000.

Well, yes and now... The Mac is big endian, and it's using a format of
%04X to print it out, so I think it's really just a visual thing.

Nope. It means that whatever returned an int/short didn't do the necessary
byte swapping under the hood they should have.

Post by Steven Palm
in the _openusb() method of commport.py, I had to insert the following
usb.UpdateLists()

UpdateLists is called automatically on import of the usb module. It
should also be called before each round of auto-probes although I
don't know if that is coded.

It is also unfortunately an unsafe function to call due to the
way libusb works. Effectively all pointers become invalidated
as they can be rejigged around.

Roger

[Steven Palm]

Post by Roger Binns

Post by Steven Palm
in the _openusb() method of commport.py, I had to insert the following
usb.UpdateLists()

UpdateLists is called automatically on import of the usb module. It
should also be called before each round of auto-probes although I
don't know if that is coded.
It is also unfortunately an unsafe function to call due to the
way libusb works. Effectively all pointers become invalidated
as they can be rejigged around.

If that line is not implemented here, it can not find the device. I
don't know what else to say, except that, at least on the Mac, it's not
enumerating and saving the state of the USB bus prior to trying to
access it at this point. I put a print statement in right under the for
bus in usb.AllBusses() loop, and it never enters the loop.

Pardon my python ignorance, but can you please point me to what
initializes this when the usb module loads, I can't find it.

As for the "auto" scan bit, I'm not doing those at present on the Mac,
so if it's counting on them, that would explain it.

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Roger Binns]

Post by Steven Palm
Pardon my python ignorance, but can you please point me to what
initializes this when the usb module loads, I can't find it.

I was wrong. If you look in native/usb/usb.py, all immediate statements
are executed. In particular usb_init is called (which is what I was
confusing with UpdateLists).

However usbscan() in usbscan.py in the main code does call UpdateLists.
However that won't be called unless the user has selected auto, or
browses the ports.

I have updated commport.py so that devices are always closed before
opening a new one, and the USB bus is re-scanned before any USB
opens.

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.

Roger

[Steven Palm]

Post by Roger Binns
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 - ***@n9yty.com
-. ----. -.-- - -.--

[Steven Palm]

Post by Steven Palm
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.

Well, I've properly reworked the darwin implementation of libusb and
it seems quite happy now... It can do things it never dreamed of
before. :-)

Because of the fact that the MacOS will allow you to interact somewhat
with devices even if they are opened exclusively by other processes, I
took advantage of that. I treat all requests to open a device as
"partially" successful even if they fail to gain exclusive access.
Then, in other parts of libusb, things are allowed or disallowed based
on the type of open they managed to get... So, you can get device
information, descriptor, interfaces, etc, but you can NOT set
configuration/etc. You can enumerate and claim interfaces, though,
provided they are not used by the system.

So, with this new and improved (?) version of libusb, you get
something like this from usbscan.py:

UsbScan 7 December 2003

usb::026::002::0:
active: True available: False
description: USB Device - Vendor 0x5ac Product 0x8203 (Interface 0)
libusb: True usb-interface: 0 usb-product: 33283 usb-vendor: 1452

usb::059::002::1:
active: True available: False
description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 1)
libusb: True usb-interface: 1 usb-product: 24576 usb-vendor: 4100

usb::059::002::2:
active: True available: True
description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 2)
libusb: True usb-interface: 2 usb-product: 24576 usb-vendor: 4100

...and it works even with the MacOS X driver loaded to supply
/dev/cu.usbmodemXXX drivers for PPP access.

I will send this over to the darwin guy at libusb and see what he
thinks. I'll also start working on the comscan.py module to return
something meaningful for the Mac. Hopefully. ;-)

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Steven Palm]

Post by Steven Palm
Well, I've properly reworked the darwin implementation of libusb and
it seems quite happy now... It can do things it never dreamed of
before. :-)

Just received word back from the Darwin port maintainer of libusb -
the changes will be incorporated into the CVS tree soon.

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--

[Roger Binns]

Post by Steven Palm

Post by Steven Palm
Well, I've properly reworked the darwin implementation of libusb and
it seems quite happy now... It can do things it never dreamed of
before. :-)

Just received word back from the Darwin port maintainer of libusb -
the changes will be incorporated into the CVS tree soon.

Does it require any changes to the usb.py code in BitPim?

Roger

[Steven Palm]

Post by Roger Binns

Post by Steven Palm
Just received word back from the Darwin port maintainer of libusb -
the changes will be incorporated into the CVS tree soon.

Does it require any changes to the usb.py code in BitPim?

Not a single line of code. :-) Even all the autodetect stuff is
working. WooHoo. :-)

-. ----. -.-- - -.--
Steve Palm - ***@n9yty.com
-. ----. -.-- - -.--