bitpim-devel — For bitpim developers

Re: [Bitpim-devel] Licensing (again :-)

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

V2.0 looks basically OK, but what is the point of section 8.  It seems
to say that if you embed the software (bitpim) in your own application
and hide it really well, then the license basically no longer applies. 
You can charge whatever you want, not give out source code, not report
modification back to the authors, and not acknowledge the code.  I guess
this neatly deals with the "problem" of embedded device manufacturers
improperly including GPL'd code in their products by just declaring such
inclusion.  Since my contribution to BitPim (drivers for some phones) is
a likely target for embedding in other applicaitons, I am not entirely
happy with this.  I would prefer someone embedding my code to either
acknowledge my code (the dreaded BSD advertising clause), or make their
source code open (the viral GPL).

The comment that some 3rd party components would not work if BitPim was
GPL got me looking at the licenses of those components, which brought me
to the wxWidgets license which is basically LGPL, except if you
distribute binary, then do whatever you want.  I guess what that is
saying, is, if you distrubute binaries, do whatever you want but don't
blame the authors, or if you distribute source code, then here are the
rules so that it plays nicely with other free software.

				Stephen

Re: [Bitpim-devel] Licensing (again :-)

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

On Mar 3, 2004, at 12:04 AM, Roger Binns wrote:
> I would like to go ahead with this, but need the consent of
> the other copyright holders (ie your name is on one or more
> source files).

  I give full consent for any portions of the code I have authority to 
speak for. ;-)

Re: [Bitpim-devel] Audiovox CDM 8900

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

> Sorry, I shouldn't have been so trite in my previous response.

You were not trite and were in fact spot on :-)

> Let me know if I can help out with the 8900. I have a limited amount of
> time to dedicate to it, but I'll try to do what I can.

The main thing I need is pointers to research people have already
done, and especially any sync protocols.  There do appear to be
various threads on Howard Forums, but they wonder all over the place.
I do have the Curitel PC Sync app so I will have a look at that.

Roger

Re: [Bitpim-devel] Audiovox CDM 8900

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

> Try using the com port that is assigned to the modem. At least that's what
> seems to work. ;)

Thanks for that.  It was the one thing I didn't try :-)

So it turns out that even though the circuit board is identical to the VX6000,
the cable is identical, the drivers are identical (just different USB ids in
the inf files), and it being a composite device (in exactly the same way),
the crucial difference is that the VX6000 (and VX4400) use the seperate
diagnostics port and the 8900 uses the modem port for both modem and
diagnostics.

There are occasions when a little knowledge is a dangerous thing :-)

Roger

Re: [Bitpim-devel] Audiovox CDM 8900

[Chris F. <cf...@za...>]

Roger

Sorry, I shouldn't have been so trite in my previous response.

I'm a Telus customer and I've been playing with the CDM-8900 and BitPim
since November. I have never had any success getting the handset to
communicate over the diagnostic port. The com port that is assigned to the
modem works quite well though, and so I haven't spent much time
investigating why the diagnostic connection doesn't respond.

Let me know if I can help out with the 8900. I have a limited amount of
time to dedicate to it, but I'll try to do what I can.

Chris...

On Wed, 3 Mar 2004, Roger Binns wrote:

> I now have an Audiovox CDM 8900 thanks to RPI Wireless.  However I
> cannot get it to talk.  The modem side works fine.  On the diagnostics
> connection, I can quite happily send any commands or traffic and it
> never returns a single byte of data.  Is there some magic mojo or
> something else I am missing.  I experienced this on two different
> Windows XP machines and a Linux.
>
> SW version  T095VEDT20_0.189
> HW version  TX-95C_REV_02
>
> RPI got it off eBay so there may be some unknown history behind it.
>
> Roger
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel
>

Re: [Bitpim-devel] Audiovox CDM 8900

[Chris F. <cf...@za...>]

Roger

Try using the com port that is assigned to the modem. At least that's what
seems to work. ;)

Chris...

On Wed, 3 Mar 2004, Roger Binns wrote:

> I now have an Audiovox CDM 8900 thanks to RPI Wireless.  However I
> cannot get it to talk.  The modem side works fine.  On the diagnostics
> connection, I can quite happily send any commands or traffic and it
> never returns a single byte of data.  Is there some magic mojo or
> something else I am missing.  I experienced this on two different
> Windows XP machines and a Linux.
>
> SW version  T095VEDT20_0.189
> HW version  TX-95C_REV_02
>
> RPI got it off eBay so there may be some unknown history behind it.
>
> Roger
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel
>

Re: [Bitpim-devel] Phone programming status

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

> protocol document describes a way to check the programming status by
> sending a packet with 0x0c in it (plus checksum and 7e).  

The LG phones don't have the 'not ready issue'.  For the 4400 and 6000
I don't even send the start sync command (which requires a reboot at the
end).

I do wonder if this is all to do with buffer management.

Roger

[Bitpim-devel] Audiovox CDM 8900

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

I now have an Audiovox CDM 8900 thanks to RPI Wireless.  However I
cannot get it to talk.  The modem side works fine.  On the diagnostics
connection, I can quite happily send any commands or traffic and it
never returns a single byte of data.  Is there some magic mojo or
something else I am missing.  I experienced this on two different
Windows XP machines and a Linux.

SW version  T095VEDT20_0.189
HW version  TX-95C_REV_02

RPI got it off eBay so there may be some unknown history behind it.

Roger

[Bitpim-devel] Phone programming status

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

I rushed the SCP-5500 support to get it into this latest test release. 
As a result, it has a feature in which writing to the phonebook on the
phone will sometimes throw an exception.  Repeating the "Send Phone
Data" operation WITHOUT rebooting the phone, usually succeeds.

I believe what happens is that when the phone is put into programming
mode, it is actually not ready to accept data.  A phonebook entry
written to the phone returns with the first few bytes of the packet,
prepended with at 0x18, likely some kind of not-ready error code.  I
thought of either just waiting several seconds or handing the 0x18 error
code when I recalled that the QCPLINK (http://qcplink.sourceforge.net/)
protocol document describes a way to check the programming status by
sending a packet with 0x0c in it (plus checksum and 7e).  The return
packet contains the ESN as well as 4 bytes that change value if the 0x0c
command is repeatedly sent just after putting the phone into programming
mode.

I tried this on my Sanyo phones and the packet returned the esn and 4
flags in exactly the same place as the QCP-2760 phone used in the
qcplink project.  (The Sanyo packets have less padding at the end.)

If I poll rapidly after putting the phone in write mode, the 4 flags
change state at different times.  So I just chose the flag that changed
last and used that to determine when it is safe to write to the phone.

This trick seems to work on the phones I tried it on, 4900, 8100, and
5500.  Perhaps it might be of use to other phones

				Stephen

PACKET statusrequest:
    1 UINT {'constant': 0x0c} +command

PACKET statusresponse:
    P UINT {'constant': 0x0} readyvalue
    1 UINT command
    3 UNKNOWN dunno1
    4 UINT esn
    1 UINT flag0
    14 UNKNOWN dunno2
    1 UINT ready
    1 UINT dunno3
    1 UINT flag2
    6 UINT dunno4
    1 UINT flag3
    * UNKNOWN unknown

    def writewait(self):
        """Loop until phone status indicates ready to write"""
        for i in range(100):
            req=self.protocolclass.statusrequest()
            res=self.sendpbcommand(req,
self.protocolclass.statusresponse)
            # print res.flag0, res.ready, res.flag2, res.flag3
            if res.ready==res.readyvalue:
                return
            time.sleep(0.1)

        self.log("Phone did not transfer to ready to write state")
        self.log("Waiting a bit longer and trying anyway")
        return

[Bitpim-devel] Licensing (again :-)

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

I have been made aware that it will be a really good idea to
update BitPim to use the Artistic License Version 2.0 due
to many loopholes in version 1.0.  (That is mainly due to
the age of version 1.0 back when there were fewer lawyers
and fewer scumbags).

I would like to go ahead with this, but need the consent of
the other copyright holders (ie your name is on one or more
source files).

Here is a list of issues in 1.0:

http://dev.perl.org/perl6/rfc/211.html

Here is 2.0:

http://dev.perl.org/perl6/rfc/346.html

Note that I am not proposing dual licensing.  Several of the
3rd party components would not work if BitPim was GPL, and
there is no value in BitPim being LGPL.

One of my major concerns is people making modified versions
of BitPim and misrepresenting them as the main version as has
happened once already.  AL 2.0 absolutely locks that down.
It also ensures that redistributed versions are open source.

Roger

Re: [Bitpim-devel] 0.7test5 build ready?

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

I think it is at a stable point for test5 now.  The 5500 phonebook can
be read and written without timeouts and seems to be correct.

Having packet descriptions is really amazing.  I have the buffer
read/write routines copied into com_sanyo5500, but once I tweak things a
little, the only code for phonebook access will be a sendpbcommand
wrapper.  Of course the 5500 packet description will be pretty large.

				Stephen


On Sun, 2004-02-29 at 15:04, Roger Binns wrote:
> Stephen,
> 
> Have you done everything you need for the test5 build?  I have rebuilt the help
> with your most recent changes.
> 
> Roger
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[Bitpim-devel] 0.7test5 build ready?

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

Stephen,

Have you done everything you need for the test5 build?  I have rebuilt the help
with your most recent changes.

Roger

Re: [Bitpim-devel] Patch for GSM phone + MSOutlook read support

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

[Note I will not be applying any of this until after the
weekend build otherwise it won't have had sufficient
testing time]

> I'm sending a patch + zip which adds preliminary support
> for MSOutlook

Although it is a good way of thinking, the current design
doesn't treat non-phone devices as phones.  For the moment
I would prefer to keep Outlook as an import source like
CSV files, not as a phone workalike.

But please do keep thinking about it.  Synchronization 
is going to involve multiple sources and destinations
for data, and the generation of transaction logs.

> appointments.  The "Profile" classes for both probably
> need some work as I'm not really sure what goes on in
> here and where they could inherit from.

Yes, there does need to be a base Profile class.  I guess this
is the spur I need to do that.

> 1. commport.py - add some multi-character terminators,
> might slow things down, but i doubt it is a significant
> performance impact.
> 
> the problem - reads come in spurts, if say wait for a '\r'
> sometimes it will read 'line1\r line2\r line3\r" and
> other times it will return right away after "line1\r"

As far as I can tell you actually need a method corresponding
to the normal Python readline method.  I think that is best
placed in the comm port class.

The reason for the "spurts" is due to lazyness (-ish :-) I
didn't want to have to implement any form of buffers.  There
are two ways to do the readuntil.  One is read one byte at 
a time.  The other is just to read as much as is available
and check the last byte.

The latter approach is very useful with the CDMA phones since
comms with them is somewhat flaky, and you can end up with
previous responses.

However this does all require fixing:

  - Adding a readline method to comm class
  - Adding buffering to comm class (especially for readline)

The comm class needs a method of sending AT commands and
reading the responses, including dealing with echoed commands, OK/ERRORs
and resets.

Can you post what a sequence of commands normally looks like?

> 2. gui.py - skip over serial init routines for non-serial
> devices, tests for existance + trueness of variable in **Phone
> class.

That is only needed if Outlook is treated as a phone which I would
prefer to avoid for the moment.

> 3. GSM driver - labelled as generic, but is probably Samsung
> S105 specific, for sure the calendar stuff is, the phone numbers
> should be generic enough to work across multiple models/vendors.

I think the best thing to do is make a com_obex.py file that does
the GSM stuff and then inherit specific models from that deal
with specific quirks.

Can you also think a bit more about how to specify the protocol
itself?  The current packetdescription stuff is perfect for
binary encodings, but not best suited for CSV style encoding.
I am thinking that printf/scanf style encoding of the packets may
be a better way of dealing with it, quoting issues (double quotes 
and commas in fields), character set encoding etc.

> i added two new classes com_nofiles.py (the non-brew starting point) 

That definitely needs to be added, together with the base
Profile.

The Outlook stuff looks good.  I will have to change the COM gencache
stuff since that won't work in a distributed binary build.

Thanks for the code and updates!

Roger

Re: [Bitpim-devel] Window position/size saving

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

Steven Palm wrote:
> On Feb 26, 2004, at 11:24 PM, Roger Binns wrote:
> > I have found one tiny problem which is that wxWidgets (on Windows
> > anyway)
> > doesn't know about multiple monitors.  It only returns information
> > about
> > the first monitor.
> 
>   I think it's the same on the Mac. At least I find that preferable to
> what X does on the Mac with mutliple monitors, you just get one huge
> destktop and so a "centered" window splits across two screens. Pros and
> Cons I guess, take your pick how you like it. :-)

The problem is that I put the app on the second screen, and every time
I restart it, it keeps ending up back on the first screen.

Roger

[Bitpim-devel] Patch for GSM phone + MSOutlook read support

[Scott H. <sco...@us...>]

I'm sending a patch + zip which adds preliminary support
for MSOutlook and GSM phones. At the moment, both only
support reads and have problems with recurring
appointments.  The "Profile" classes for both probably
need some work as I'm not really sure what goes on in
here and where they could inherit from.

1. commport.py - add some multi-character terminators,
might slow things down, but i doubt it is a significant
performance impact.

the problem - reads come in spurts, if say wait for a '\r'
sometimes it will read 'line1\r line2\r line3\r" and
other times it will return right away after "line1\r"

2. gui.py - skip over serial init routines for non-serial
devices, tests for existance + trueness of variable in **Phone
class.

3. GSM driver - labelled as generic, but is probably Samsung
S105 specific, for sure the calendar stuff is, the phone numbers
should be generic enough to work across multiple models/vendors.

I'm gonna send this out now, I'll try to comment
more on bitpim later - things I'm concerned with are the base
classes which are tied to brew and where a non-brew/non-serial
com_* interface should start from - i added two new classes
com_nofiles.py (the non-brew starting point) and
com_nonphone.py (a base class for non-serial phones). I'm
attaching a zip containing the new files and "gsmout_diff"
which is the cvs diff of the existing files.  The zipfile is
named .zep b/c comcast is being "smart" and blocking sends with
.zip file attachments.


-scott


===========

? com_gsm.py
? com_nofiles.py
? com_nonphone.py
? com_outlook.py
? p_gsm.p
? p_gsm.py
? p_sanyo5500.py
Index: commport.py
===================================================================
RCS file: /cvsroot/bitpim/bitpim/commport.py,v
retrieving revision 1.28
diff -u -r1.28 commport.py
--- commport.py	23 Feb 2004 20:54:04 -0000	1.28
+++ commport.py	27 Feb 2004 06:44:08 -0000
@@ -12,6 +12,7 @@
 import serial
 import common
 import time
+import re
 try:
     import native.usb as usb
 except:
@@ -237,15 +238,32 @@
             self.logdata("Reading remaining data", res)
         return res

+    def termmatch( self, char, buf ):
+        if ( len(buf) == 0 ):
+            return False
+        elif ( char == '\r\n' and len(buf) > 1 and buf[-1] == '\r' and
buf[-2] == '\n' ):
+            return True
+        elif ( char == "OKEOL" ):
+            if ( re.search("(OK)|(ERROR)[\n\r]+$", buf ) ):
+                return True
+            else:
+                return False
+        elif ( char == "EOL" and ( buf[-1] == '\r' or buf[-1] == '\n' ) ):
+            return True
+        elif ( char == buf[-1] ):
+            return True
+        return False
+
     def readuntil(self, char, log=True, logsuccess=True, numfailures=0):
         # Keeps reading until it hits char
         self.readrequests+=1
-        if False: # don't log this anymore
-            self.logdata("Begin reading until 0x%02x" % (ord(char),), None)
+        if log: # don't log this anymore
+            self.logdata("Begin reading until 0x%02x" % (ord(char[0]),),
None)

         # set numfailures to non-zero for retries on timeouts
         res=''
-        while len(res)==0 or res[-1]!=char:
+        while not self.termmatch( char, res ):
+
             if hasattr(self.ser, 'readuntil'):
                 # usb does it directly
                 res2=self.ser.readuntil(char)
@@ -253,12 +271,12 @@
             else:
                 b=self.ser.inWaiting()
                 if b<1: b=1
-                res2=self.read(b,0)
+                res2=self.read(b,log)
             if len(res2)<1:
                 if numfailures==0:
                     if log:
                         self.log("Timed out waiting for %02x, requested
bytes %d  - %d bytes read" %
-                                 (ord(char), b, len(res)))
+                                 (ord(char[0]), b, len(res)))
                         self.logdata("Incomplete read was", res)
                     self.readbytes+=len(res)
                     raise CommTimeout(partial=res)
Index: gui.py
===================================================================
RCS file: /cvsroot/bitpim/bitpim/gui.py,v
retrieving revision 1.114
diff -u -r1.114 gui.py
--- gui.py	24 Feb 2004 17:40:05 -0000	1.114
+++ gui.py	27 Feb 2004 06:44:10 -0000
@@ -1016,6 +1016,10 @@

     def setupcomm(self):
         if __debug__: self.checkthread()
+        # FIXME: Is there a cleaner way to handle this?
+        if getattr( self.dispatchto.phonemodule.Phone,
'isNonSerialDriver', False ):
+            self.commphone=self.dispatchto.phonemodule.Phone(self, None)
+            return
         if self.commphone is None:
             import commport
             if self.dispatchto.commportsetting is None or \
Index: guiwidgets.py
===================================================================
RCS file: /cvsroot/bitpim/bitpim/guiwidgets.py,v
retrieving revision 1.138
diff -u -r1.138 guiwidgets.py
--- guiwidgets.py	24 Feb 2004 17:40:05 -0000	1.138
+++ guiwidgets.py	27 Feb 2004 06:44:12 -0000
@@ -291,6 +291,8 @@
                   'SCP-5300': 'com_sanyo5300',
                   'SCP-8100': 'com_sanyo8100',
                   # 'SCP-5500': 'com_sanyo5500',
+                  'generic GSM': 'com_gsm',
+                  'MSOutlook': 'com_outlook',
                   }

     setme="<setme>"
Index: makepackets.bat
===================================================================
RCS file: /cvsroot/bitpim/bitpim/makepackets.bat,v
retrieving revision 1.9
diff -u -r1.9 makepackets.bat
--- makepackets.bat	23 Feb 2004 02:14:49 -0000	1.9
+++ makepackets.bat	27 Feb 2004 06:44:12 -0000
@@ -3,6 +3,7 @@
 python protogen.py p_lgvx4500.p p_lgvx4500.py
 python protogen.py p_lgvx6000.p p_lgvx6000.py
 python protogen.py p_brew.p p_brew.py
+python protogen.py p_gsm.p p_gsm.py
 python protogen.py p_lgtm520.p p_lgtm520.py
 python protogen.py p_lg.p p_lg.py
 python protogen.py p_sanyo4900.p p_sanyo4900.py

Re: [Bitpim-devel] Window position/size saving

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

On Feb 26, 2004, at 11:24 PM, Roger Binns wrote:
> I have found one tiny problem which is that wxWidgets (on Windows 
> anyway)
> doesn't know about multiple monitors.  It only returns information 
> about
> the first monitor.

  I think it's the same on the Mac. At least I find that preferable to 
what X does on the Mac with mutliple monitors, you just get one huge 
destktop and so a "centered" window splits across two screens. Pros and 
Cons I guess, take your pick how you like it. :-)

> It also looks like wx.GetClientDisplayRect should be called to get the
> area of the screen that isn't covered in start bars etc.  For example
> this is the output on my 1600x1200 monitor:

  I hadn't seen that in the API, I'll check it out. It would remove some 
of the "fudge factor" I had put in there. :-)

Re: [Bitpim-devel] fyi... wrote 3.5mb .mp3 ringtone to vx4500

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

> would it help development in any way to know how much
> memory the vx4500 has...

It should tell you the amount free in one of the Get It Now
screens.  The actual memory amounts are not useful as there
is no way to manage the free memory.  If you zip up all the
files visible in the filesystem you will find out that they
are larger than the amount of memory.  The filesystem itself
is some wacky combination of stuff in ROM and flash.

Roger

Re: [Bitpim-devel] fyi... wrote 3.5mb .mp3 ringtone to vx4500

[greg c. <gre...@ya...>]

would it help development in any way to know how much
memory the vx4500 has... if it would I will risk
having to trade my phone in... if not then I wont.

thanks
greg


--- Roger Binns <ro...@ro...> wrote:
> > I hope this information is usefull.
> 
> Not really :-)
> 
> > dont know what
> > effect it will have on the phones operating system
> if
> > I exceed memory using bitpim. 
> 
> I tried it on my phone once.  In the protocol the
> first 
> packet says how big the file is going to be, so the
> phone
> does know in advance if it is going to be too big. 
> Except
> they don't anything about it.
> 
> You can quite happily start writing a too large file
> until
> the file system fills up, at which point the phone
> crashes
> and goes into offline mode.  You can reboot it and
> then
> delete the file.
> 
> If the phone goes into an infinite reboot cycle
> (rare, but
> can happen with the older models) take it back to
> Verizon
> and they will replace it.
> 
> This stuff is even discussed in the Brew developer
> forums.
> There is no way programmatically to find out the
> amount
> of free memory, or to be defensive about its use. 
> The
> only known technique to find out how much is free is
> to
> fill it up.
> 
> Roger
> 
> 
>
-------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps
> Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
>
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
>
https://lists.sourceforge.net/lists/listinfo/bitpim-devel


__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

Re: [Bitpim-devel] fyi... wrote 3.5mb .mp3 ringtone to vx4500

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

> I hope this information is usefull.

Not really :-)

> dont know what
> effect it will have on the phones operating system if
> I exceed memory using bitpim. 

I tried it on my phone once.  In the protocol the first 
packet says how big the file is going to be, so the phone
does know in advance if it is going to be too big.  Except
they don't anything about it.

You can quite happily start writing a too large file until
the file system fills up, at which point the phone crashes
and goes into offline mode.  You can reboot it and then
delete the file.

If the phone goes into an infinite reboot cycle (rare, but
can happen with the older models) take it back to Verizon
and they will replace it.

This stuff is even discussed in the Brew developer forums.
There is no way programmatically to find out the amount
of free memory, or to be defensive about its use.  The
only known technique to find out how much is free is to
fill it up.

Roger

[Bitpim-devel] fyi... wrote 3.5mb .mp3 ringtone to vx4500

[greg c. <gre...@ya...>]

Trying to see how much memory was available for
ringtones... I have downloaded 3959103 bytes 3.95mb of
ringtones to the vx4500,  3.5mb in one file.  Im a
little scared to download any more... dont know what
effect it will have on the phones operating system if
I exceed memory using bitpim.  I hope this information
is usefull.

thanks
greg




__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

[Bitpim-devel] Window position/size saving

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

I have found one tiny problem which is that wxWidgets (on Windows anyway)
doesn't know about multiple monitors.  It only returns information about
the first monitor.

It also looks like wx.GetClientDisplayRect should be called to get the
area of the screen that isn't covered in start bars etc.  For example
this is the output on my 1600x1200 monitor:

>>> wx.GetDisplaySize()
wxSize(1600, 1200)
>>> wx.GetClientDisplayRect()     # taskbar at the bottom
wxRect(0, 0, 1600, 1168)
>>> wx.GetClientDisplayRect()     # taskbar on right side
wxRect(0, 0, 1495, 1200)
>>> wx.GetClientDisplayRect()     # on the top
wxRect(0, 32, 1600, 1168)         

On Linux with a Gnome desktop, GetClientDisplayRect just returns the
same numbers as GetDisplaySize.

Maybe you want to use this in the heuristics for sizing and placement.

Roger

Re: [Bitpim-devel] more files found and read on Sanyo 8100

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

On Wed, 2004-02-25 at 22:14, bfaye wrote:
> Well, another day, more progress.  
This is nice!  This means that is likely that full Bitpim support can be
developed for for the 8100 and later Sanyo phones.  I'll have to see if
your methods can lead to downloading videos from the SCP-5500.

[Bitpim-devel] more files found and read on Sanyo 8100

[bfaye <bf...@ya...>]

Well, another day, more progress.  I found that the fa0971 command is like a
"change working dir" command.  If I use a different number at offset 178, and
read out the count using fa0972, I get different numbers.  If read the
filenames after the count, I got different files.  Using 01 gets camera pics. 
02 gets vision downloads, so anything you download through the phone WAP
browser goes there, pics, ringers, and J2ME programs.  The gcd/jad and the file
itself is stored.  03 gets me pictures I've sent to my phone with the "other"
program that my friend bought.  I don't have any ringers sent to my phone, so
I'll hop over to my friend's and sent a ringtone over, and see if there is a
directory number 4, or if everything in the phone's pc sync folder.  Here is
the updated packet descriptions:
PACKET sanyochangedir:
    * sanyomediaheader {'command': 0x09, 'subcommand': 0x0071} +header
    2 UINT {'constant': 0xffff} +word
    170 UNKNOWN +pad
    1 UINT dirindex
    1 UINT {'constant': 0x00} +dunno2

PACKET sanyoinitcampicread:
    *sanyochangedir {'dirindex': 0x01} +command

PACKET sanyoinitvisiondlsread:
    *sanyochangedir {'dirindex': 0x02} +command

PACKET sanyoinitpcsyncread:
    *sanyochangedir {'dirindex': 0x03} +command


__________________________________
Do you Yahoo!?
Get better spam protection with Yahoo! Mail.
http://antispam.yahoo.com/tools

[Bitpim-devel] Re: [bitpim-cvs-checkins] bitpim com_sanyo.py,1.22,1.23

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

> +            self.log("Multiple LG packets in data - taking last one starting at "+`d+1`)
> +            self.logdata("Original LG data", origdata, None)

Those should probably blame Sanyo :-)

Roger

Re: [Bitpim-devel] Timeouts on SCP-5500

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

> Are you proposing to merge sendbrewcommand, the LG sendpbcommand and the

The LG commands are quite different from the brew ones, with different 
numbers of bytes of prefix, different values for those bytes, a
different means of error reporting etc.  The only thing they have in 
common with the brew ones is the crc and ~ terminator.  That is why
the LG and brew ones are similar but very different.

> At any rate, there is stuff in
> the LG sendcommand, like CRC checking, that you added since I forked the
> Sanyo one that I should have in the Sanyo code.

Maybe the routine can be split in two with the framing, crc checking etc handled 
as common code and a higher level that does the actual composition of
bytes, generates exceptions on return etc?

> Is there anyther usb monitor program that you recommend other than
> snoopypro?

I think I used ordinary snoopy, but was very unimpressed.

Roger