Menu
▾
▴
bitpim-devel
|
From: Steven P. <n9...@n9...> - 2003-12-15 19:10:57
|
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 - n9...@n9...
-. ----. -.-- - -.--
|
|
From: Roger B. <ro...@ro...> - 2003-12-15 19:20:58
|
> usb_os_open: 0410:0060
> 059/002 0410/0060
It is having byte ordering issues. Those should be 1004 and 6000.
> - Unable to fetch manufacturer string
> - Unable to fetch product string
That is normal.
> 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
|
|
From: Steven P. <n9...@n9...> - 2003-12-15 21:45:09
|
On Dec 15, 2003, at 1:21 PM, Roger Binns wrote:
>> 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 - n9...@n9...
-. ----. -.-- - -.--
|
|
From: Roger B. <ro...@ro...> - 2003-12-15 22:46:17
|
> * 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. > * 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 have no idea what that is about. The gauge is in the status bar at the bottom. > 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. > * 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 |
|
From: Steven P. <n9...@n9...> - 2003-12-16 04:12:25
|
On Dec 15, 2003, at 4:46 PM, Roger Binns wrote: >> * 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. >> * When trying to import wallpaper into bitpim, I get a segfault: >> > 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. >> 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. > 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 - n9...@n9... -. ----. -.-- - -.-- |
|
From: Roger B. <ro...@ro...> - 2003-12-16 07:18:46
|
> 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. >> 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. > 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), > 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 |
|
From: Roger B. <ro...@ro...> - 2003-12-15 23:33:45
|
>> 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. > in the _openusb() method of commport.py, I had to insert the following > call: > > 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 |
|
From: Steven P. <n9...@n9...> - 2003-12-16 04:06:03
|
On Dec 15, 2003, at 5:33 PM, Roger Binns wrote: >> in the _openusb() method of commport.py, I had to insert the >> following >> call: >> >> 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 - n9...@n9... -. ----. -.-- - -.-- |
|
From: Roger B. <ro...@ro...> - 2003-12-16 06:22:51
|
> 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 |
|
From: Steven P. <n9...@n9...> - 2003-12-16 16:01:17
|
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... -. ----. -.-- - -.-- |
|
From: Steven P. <n9...@n9...> - 2003-12-16 17:42:30
|
On Dec 16, 2003, at 10:01 AM, Steven Palm wrote: > 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 - n9...@n9... -. ----. -.-- - -.-- |
|
From: Steven P. <n9...@n9...> - 2003-12-16 20:57:47
|
On Dec 16, 2003, at 11:42 AM, Steven Palm wrote: > 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 - n9...@n9... -. ----. -.-- - -.-- |
|
From: Roger B. <ro...@ro...> - 2003-12-16 21:16:17
|
Steven Palm wrote: > On Dec 16, 2003, at 11:42 AM, Steven Palm wrote: >> 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 |
|
From: Steven P. <n9...@n9...> - 2003-12-16 22:00:22
|
On Dec 16, 2003, at 3:16 PM, Roger Binns wrote: >> 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 - n9...@n9... -. ----. -.-- - -.-- |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X