bitpim-devel — For bitpim developers

Re: [Bitpim-devel] Any Windows registry API experts?

[Jim <Ji...@ja...>]

Roger,

  Which key?  or can you give me the tree (export from regedit) and I'll look
at it.  I've done some registry stuff from both C++ and Python.  It's a beast
at best.

Jim West
www.jameswest.com

The box said Windows 95 or better, so I installed Linux.


---------- Original Message -----------
From: "Roger Binns" <ro...@ro...>
To: <bit...@li...>
Sent: Tue, 16 Dec 2003 02:12:25 -0800
Subject: [Bitpim-devel] Any Windows registry API experts?

> Are there any Windows registry API experts on this list?
> 
> I am having some difficulty with Windows doing something
> stupid and I can't figure out why.
> 
> RegQueryInfoKey tells me there are 22 children of the key I
> am interested in.
> 
> Regedit shows 22 children.
> 
> RegEnumKey returns strings for the first 18 index values,
> and then returns error 234 (More data available) for the
> next 4, and then returns 259 (No more data).
> 
> Why is more data available returned and how do I actually
> get it give me the last 4 children?  Nothing I have tried
> works.  And howcome regedit can show the last 4?
> 
> Roger
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel
------- End of Original Message -------

[Bitpim-devel] Any Windows registry API experts?

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

Are there any Windows registry API experts on this list?

I am having some difficulty with Windows doing something
stupid and I can't figure out why.

RegQueryInfoKey tells me there are 22 children of the key I
am interested in.

Regedit shows 22 children.

RegEnumKey returns strings for the first 18 index values,
and then returns error 234 (More data available) for the
next 4, and then returns 259 (No more data).

Why is more data available returned and how do I actually
get it give me the last 4 children?  Nothing I have tried
works.  And howcome regedit can show the last 4?

Roger

Re: [Bitpim-devel] libusb / Darwin

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

>   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

Re: [Bitpim-devel] libusb / Darwin

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

>   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

Re: [Bitpim-devel] libusb / Darwin

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

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...
-. ----. -.-- - -.--

Re: [Bitpim-devel] libusb / Darwin

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

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...
-. ----. -.-- - -.--

Re: [Bitpim-devel] libusb / Darwin

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

>> 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

Re: [Bitpim-devel] libusb / Darwin

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

>   * 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

Re: [Bitpim-devel] libusb / Darwin

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

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...
-. ----. -.-- - -.--

Re: [Bitpim-devel] libusb / Darwin

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

> 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

[Bitpim-devel] libusb / Darwin

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

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...
-. ----. -.-- - -.-- 

Re: [Bitpim-devel] Changing device name under Linux

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

> Maybe a reboot should close the connection by
> default.

That would make sense.

The other thing that closing the connection causes is
reiteration of interfaces if the 'auto' port has been chosen.

Roger

Re: [Bitpim-devel] Changing device name under Linux

[Stephen W. <sa...@us...>]

Adding dictionary words to request a reboot and connection close sounds
like a good idea.  Maybe a reboot should close the connection by
default.  Unless it is an old phone using a real serial interface, the
device is going to go away anyway.  (I might try taking on adding
support for a Samsung SCH-3500, an old phone that I have a serial cable
for.)

			Steve

Re: [Bitpim-devel] Changing device name under Linux

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

> If I put "save.close()" as the last line of my savephone method, then
> the phone gets assign ttyACM0 when it reboots.  (Or maybe I was lucky).
> Is it OK to do this close at this point?

I don't think it will work, as the rest of the code won't attempt
to reopen a closed port.

To get the desired effect you should really be calling 
WorkerThread.clearcomm.

I think the best way of dealing with this inspired by http.  In
the dictionary you return, the following two keys can be added:

   'connection':  value can be 'close' and WorkerThread will
                  close it for you
   'reboot':      value can be True or False.  If True, then the
                  phone will be rebooted.  In the future this
                  could be controlled by the gui (ie auto-reboot
                  when needed, or let the user do it)

If that sounds ok, I will implement it at some point.

Roger

[Bitpim-devel] Changing device name under Linux

[Stephen W. <sa...@us...>]

Under linux, my Sanyo phone uses the ACM driver, so I talk to it with
the device /dev/input/ttyACM0.  When I update (overwrite really) the
phonebook, thet last thing that happens is that the phone is told to
reboot.  When the phone reboots, linux, assigns the phone to
/dev/input/ttyACM1.  I think this is because BitPim may still have the
device open at the time that the phone comes on again, so linux assigns
it the next free device name.

If I put "save.close()" as the last line of my savephone method, then
the phone gets assign ttyACM0 when it reboots.  (Or maybe I was lucky). 
Is it OK to do this close at this point?

					Steve

Re: [Bitpim-devel] libusb

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

Here is an example of comscan on my machine.  [I would
have included this in the last message, except I found
a bug in comscan that I have now fixed]

COM1:
 active: True  available: True  description: Communications Port (COM1)
 driverdate: (2001, 7, 1)  driverdescription: Communications Port
 driverprovider: Microsoft  driverversion: 5.1.2600.0
 hardwareinstance: ACPI\PNP0501\1

COM2:
 active: True  available: True  description: Communications Port (COM2)
 driverdate: (2001, 7, 1)  driverdescription: Communications Port
 driverprovider: Microsoft  driverversion: 5.1.2600.0
 hardwareinstance: ACPI\PNP0501\2

COM5:
 active: False  available: False
 description: Prolific USB-to-Serial Comm Port (COM5)
 driverdate: (2002, 4, 9)
 driverdescription: Prolific USB-to-Serial Comm Port
 driverprovider: Prolific  driverversion: 1.5.0.0
 hardwareinstance: USB\VID_067B&PID_2303\6&32D8FA8&0&3

COM6:
 active: True  available: True
 description: Prolific USB-to-Serial Comm Port (COM6)
 driverdate: (2002, 4, 9)
 driverdescription: Prolific USB-to-Serial Comm Port
 driverprovider: Prolific  driverversion: 1.5.0.0
 hardwareinstance: USB\VID_067B&PID_2303\6&32D8FA8&0&4

COM1 and COM2 are the onboard ports.  COM5 and COM6 are the USB to serial
ports.  Note how I can detect the USB info in the hardwareinstance.
The reason why it lists both COM5 and 6 is that I have a hub
and it assigns each position in the hub a different hardware
instance.  I only have one cable so it doesn't matter, but
if I had 4 cables it would be needed to tell the difference.
That is also why COM5 is neither active nor available since
it isn't plugged in.

Roger

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

Re: [Bitpim-devel] libusb

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

On Dec 12, 2003, at 11:57 PM, Roger Binns wrote:
> That is what the native/usb/usb.py code does as a test, but isn't
> what bitpim proper does.  BitPim invokes usbscan.py in the main
> code to get a list of all USB devices and names them
> usb::bus::device::interface

  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?  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.

> comdiagnose then picks out what devices from the output of comscan.py 
> and usbscan.py are likely to be phones or USB to serial cables.

  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.

>>   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.
>
> What if there are multiple devices with the same details?

  You actually get an iterator object that would cover all matching 
interfaces for your specification.

> You can build a seperate interface for USB if you want to instead
> of using libusb.  You can see another example in native/wab
> where I actually wrote my own code for Python interfacing.

  Okay, this will bear more thinking things through, then.

  I see that you have a usbdb list of phones supported and their 
vendor/product/config/interface information. This would be once source 
to use for just trying to see if the interfaces could be opened, and if 
so, put them in the list (for the Mac, at least). I see you have some 
USB->serial cables there with no interface listed. Do these connect as 
USB or through a device entry?

  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. :-)

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

Re: [Bitpim-devel] libusb

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

> The
> current logic being used seems to want to walk the tree looking for a
> match with vendor and product code on a device, and then get it's
> second interface, but since you cannot open the device this whole
> approach falls apart.

That is what the native/usb/usb.py code does as a test, but isn't
what bitpim proper does.  BitPim invokes usbscan.py in the main
code to get a list of all USB devices and names them 
usb::bus::device::interface

comdiagnose then picks out what devices from the output of
comscan.py and usbscan.py are likely to be phones or USB
to serial cables.

The reason for using names is so that particular devices can
be selected.  As a worst case example, here is usbscan output
for my machine with a USB to serial cable, a VX4400 and a
VX6000 plugged in.

UsbScan 7 December 2003

usb::001::016::0:
 active: 1  available: 0 
 description: USB Device - Vendor 0x4b8 Product 0x5 (Interface 0)  libusb: 1 
 usb-interface: 0  usb-product: 5  usb-vendor: 1208 

usb::001::020::0:
 active: 1  available: 0 
 description: USB Device - Vendor 0x67b Product 0x2303 (Interface 0) 
 libusb: 1  usb-interface: 0  usb-product: 8963  usb-vendor: 1659 

usb::001::022::1:
 active: 1  available: 0 
 description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 1) 
 libusb: 1  usb-interface: 1  usb-product: 24576  usb-vendor: 4100 

usb::001::022::2:
 active: 1  available: 1 
 description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 2) 
 libusb: 1  usb-interface: 2  usb-product: 24576  usb-vendor: 4100 

usb::001::021::1:
 active: 1  available: 0 
 description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 1) 
 libusb: 1  usb-interface: 1  usb-product: 24576  usb-vendor: 4100 

usb::001::021::2:
 active: 1  available: 1 
 description: USB Device - Vendor 0x1004 Product 0x6000 (Interface 2) 
 libusb: 1  usb-interface: 2  usb-product: 24576  usb-vendor: 4100 


>   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. 

What if there are multiple devices with the same details?

>   The question becomes, how to hack libusb so it will work or, if that
> falls through, write a separate access routine for the Mac, at least
> the 'open/init' bit.

You have to call usb_open in order to call usb_claim_interface in
libusb.  The actual opening of a device happens in _openusb in
commport.py.

You can build a seperate interface for USB if you want to instead
of using libusb.  You can see another example in native/wab
where I actually wrote my own code for Python interfacing.

Roger

Re: [Bitpim-devel] libusb

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

On Dec 12, 2003, at 3:06 PM, Steven Palm wrote:
>  Either you *CAN* grab the interfaces separately from the device as a 
> whole, thus allowing the kernel driver to handle the serial_com 
> interfaces and leaving the vendor_specific interface for you, *OR* you 
> can NOT grab them separately in which case I don't know how you'd get 
> it to work. ;-)

  Okay, my head is starting to settle down a little bit... Thanks to 
someone at Apple, I am a little closer here. I was able to throw 
together some sample code and actually open the data interface on the 
phone... But, the question is, how to make this method compatible with 
libusb and bitpim....

  Due to the way composite devices work on MacOS X, at least CDC devices 
in particular, you can NOT open the device, as there is no way to 
wrestle control away from the kernel extension that has it open. The 
current logic being used seems to want to walk the tree looking for a 
match with vendor and product code on a device, and then get it's 
second interface, but since you cannot open the device this whole 
approach falls apart.

  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. This shouldn't 
pose a massively huge problem, because you know the 
vendor/product/interface number already, and the code appeared to only 
be using the first configuration so this is fine as well.

  The question becomes, how to hack libusb so it will work or, if that 
falls through, write a separate access routine for the Mac, at least 
the 'open/init' bit.

  What do you think?

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

Re: [Bitpim-devel] libusb

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

On Dec 9, 2003, at 11:54 PM, Roger Binns wrote:
> That is your phone.  The libusb api has you claiming the
> interfaces seperately from the device as a whole.  On Linux
> you can't claim an interface if there is a device driver
> attached, but the acm driver only attaches to interface
> 0 & 1  (interrupt and data for the modem) and leaves the
> diagnostics interface (2) seperate.  I don't know how you
> get around it.

  Let me get this straight, because I think I'm reading that both 
ways....

  Either you *CAN* grab the interfaces separately from the device as a 
whole, thus allowing the kernel driver to handle the serial_com 
interfaces and leaving the vendor_specific interface for you, *OR* you 
can NOT grab them separately in which case I don't know how you'd get 
it to work. ;-)

(from another e-mail, you write)
> that).  The second bit looks to be the driver it attached but it 
> doesn't
> look like it gave you a device name.

  Not all USB devices on MacOS are actually assigned a filesystem device 
name. They aren't accessed by that anyway... If you look at the libusb 
code, darwin.c in particular, you'll see the way to enlightenment on 
MacOS by stepping through IOKit for enumerated devices and interfaces 
on them. The trouble is, as far as I can tell, that if MacOS X assigns 
a driver to the device you can not open it to enumerate the interfaces.

  I'm working on it... ;^)

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

Re: [Bitpim-devel] Windows binaries on Mac?

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

On Dec 12, 2003, at 2:01 AM, Roger Binns wrote:
> BitPim 0.7 has support for sound conversion to and from the
> PureVoice stuff Qualcomm uses.  This is done by two binaries.
> One is ffmpeg which is GPL and provided as source, so it can
> be compiled for anything.  It is used to convert any audio
> source into mono 8KHz pcm.
>
> The second binary is PVConv.exe which is from Qualcomm and
> only available for Windows.  It is a trivial command line
> only tool that does the conversion between mono 8KHz pcm
> and purevoice (or back again).  The binary runs perfectly
> on Linux if you have Wine installed.
>
> So what happens on Mac?

  It won't work. The only way to run Windows binaries on the Mac is 
through either the bochs emulator or VirtualPC.  And even then, I'm not 
sure if there is a "nice" way to handle the interaction. Interestingly 
enough, though, Apple has a QuickTime codec for Qualcomm's PureVoice. I 
wonder if it's the same format (or possible to strip it out) and then 
also how much work is it to access this from Python...

  I'll look into this after the USB issue.

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

Re: [Bitpim-devel] Mac bundle procedure....

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

# myapp.includePackages.append(c)

That probably doesn't work as c includes the .py in the filename.
Have you tried:

myapp.includePackages.append(c[:-3])

Roger

[Bitpim-devel] Windows binaries on Mac?

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

BitPim 0.7 has support for sound conversion to and from the
PureVoice stuff Qualcomm uses.  This is done by two binaries.
One is ffmpeg which is GPL and provided as source, so it can
be compiled for anything.  It is used to convert any audio
source into mono 8KHz pcm.

The second binary is PVConv.exe which is from Qualcomm and
only available for Windows.  It is a trivial command line
only tool that does the conversion between mono 8KHz pcm
and purevoice (or back again).  The binary runs perfectly
on Linux if you have Wine installed.

So what happens on Mac?

Roger

[Bitpim-devel] Images and ringtones in CVS version

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

Just so that noone who is working from CVS is surprised:

I am currently upgrading the code that deals with ringtones
and wallpapers.  The ringtone tab contents will appear not
to work.  Don't try and do anything with it.

The wallpaper tab will now read data from multiple locations.
This is needed for the VX6000 which has 3 different locations
for images (Brew, MMS and DRM) as well as the camera, plus of
course the builtin images.

For anyone who has a 6000, do try and read wallpapers and you
should see it reading everything.  Don't try and write yet.

Roger