[Kde-pim] Reason why the 700p doesn't sync...

Sat Feb 24 19:30:25 GMT 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason 'vanRijn' Kasper wrote:
> Hi Ryan!!  =:)
> 
> On Friday 23 February 2007 18:56, Ryan Novosielski wrote:
>> Hello folks... I am attempting to sync my Palm Treo 700p. I had a 650
>> which was great in every way (save EVDO and NVRAM), but when the boss
>> bought me a cell, I opted for a Treo 700p.
> 
> I have a vested interest in getting this to work, since at some point, I'd 
> love to get a 700p for myself...  =:)

Here's another place I have some suggestions... The 700p and 650 both
work fine for both USB and BT sync. Unfortunately, though, it's a bit of
a chore as-is to kpilot sync both ways sporadically (change the device
string, but that's not really ideal -- to have to go into config dialog
boxes). It would be nice if there were someplace to choose a device from
the front page, perhaps the ability to have different profiles that are
easily chosen without diving into dialogs. USB is significantly faster,
but BT is significantly more convenient if you happen not to have a
cable on you.

>> Well, the thing won't reliably sync by USB and it has finally occurred
>> to me why. The 700p, when plugged in, draws power and alerts the PC to
>> its presence. The problem, however, is if one opens kpilot, kpilot
>> notices the open port and doesn't hold off like it apparently normally
>> would before attempting to open a USB port (Pilot device /dev/ttyUSB1
>> does not exist -- probably it is a USB device and will appear during a
>> HotSync).
> 
> One thing to try right away:  go to kpilot's configuration dialog | General 
> Setup | Device and set "Workarounds" to something other than None.  You also 
> need to make sure that you're using at least kpilot 4.9.0 (from KDE 3.5.6).  
> If you're using kpilot 4.9.0, then this might address what you're seeing. 
> KPilot in the current development environment does something different 
> entirely (hopefully in a better way), so I'd like you to try using the 
> workarounds flag first to see if it helps and if it doesn't you'll need to 
> try the latest version of kpilot so I can hack it into submission for you.  
> =:)

I am running 4.9.0 on KDE 3.5.6. This appears to do the trick. I've
synced twice now and I can unplug and replug the device and it will
still work properly (no jumps to higher USB ports).

It is worthwhile to note that I have extremely frequently had problems
with kpilot and the kpilotDaemon. It seems like exiting kpilot, at least
on my machine, generally FUBAR's the Daemon process. I often see it
sitting down there with no icon. In fact, this time I had two different
problems getting to where you wanted me to go. First I went to the
config and kpilot froze. I then erased everything (find ~ -name
"*kpilot*" -exec rm -rf {} \;) and tried again, and instead of picking
wizard like I normally do, I picked dialog. Same deal. The third time, I
killed everything, waited a little, removed everything again, waited a
little bit and finally tried the same thing and was able to get into the
config dialog there. I don't know why this has been so troublesome, but
I've had problems like that on two different laptops now.

> [snip]
>> The same thing happens with pilot-xfer. The only way to make this work
>> is to make sure the device is already syncing by the time it causes a
>> device to appear on the PC. This is tricky, however, because it doesn't
>> seem like you have an unlimited amount of time to get the PC properly
>> connected after pushing HotSync on the device -- it only appears to work
>> for the first few seconds.
> 
> Now this concerns me here.  Kpilot can only do what pilot-link can do since 
> pilot-link is the underlying library for kpilot.  However, searching google 
> briefly shows that at least some people are able to get jpilot working with 
> the 700p, so we have some level of hope.  =:)
> 
> Why is /dev/ttyUSB1 staying open when you try syncing with pilot-xfer?  I'm 
> assuming you're doing it like this:
> 
> - make sure kpilot isn't running
> - hit hotsync on your treo
> - type this and hit enter:
> 
> pilot-xfer -p /dev/ttyUSB1 -l
> 
> Is that right?  If so, I don't understand why /dev/ttyUSB1 is kept open.

That tends to work. Running pilot-xfer first is what will screw that up.
However, you don't get an unlimited amount of time to hit HotSync and
then do pilot-xfer... seems like voodoo getting that to work exactly
properly. A couple of tries and it will definitely have worked, but it's
not like what I'm used to where I have something running, connect the
Palm (or have had it connected -- doesn't matter) and hit HotSync
whenever I feel like. This is now how kpilot is working with the
workaround, so many kudos.

> Kpilot will see the device and try to communicate with it and won't let it go 
> in time for the comm to happen, which is why I would like you to try 
> the "Workarounds" thing above.

What does that workaround do precisely? That's somewhat interesting to me.

> Failing that... if it's predictable and consistent, have you tried just 
> using /dev/ttyUSB3 always?

Yes. That doesn't work though. If you have it set to /dev/ttyUSB3,
kpilot will hang out on /dev/ttyUSB3 and the Palm will go from
/dev/ttyUSB1 (charging) and then back to /dev/ttyUSB1 for comm. If
kpilot has touched the port, the Linux USB will assign the Palm some
other address to avoid it -- every time.

>> Anyway, it appears as if this is the problem. Now, how on earth can we
>> go forward from here? Does this description make sense to anyone? Here's
>> an example with pilot-xfer:
>>
>> BAD:
>> 1. Connect device. (/dev/ttyUSB0-1 created)
>> 2. Run pilot-xfer (listens to /dev/ttyUSB1)
>> 3. Hit HotSync (/dev/ttyUSB0-1 go away, /dev/ttyUSB2-3 appear)
>> 4. Eventual failure
>>
>> GOOD:
>> 1. Connect device. (/dev/ttyUSB0-1 created)
>> 2. Hit HotSync (/dev/ttyUSB0-1 are destroyed and then re-created)
>> 3. Run pilot-xfer (listens and connects on /dev/ttyUSB1)
>> 4. Success
>>
>> Thanks for reading this far and hopefully it was helpful.
> 
> Thanks for the well-put-together e-mail Ryan.  =:)
> 
> Please let me know what you find.  I'd love to get this working for you.  =:)

Seems as if you already have. Now, it would be neat if there were ways
to make this less like voodoo. :) Seems to me that one way would be to
read the device string on the device, but actually, if I'm not mistaken,
the Treo 700p and 650 report the same way... having owned both, I can
say that they do NOT HotSync the same way. At a minimum, though, you
might want to toss 700p on the end of the "Zire 31, 72, Tungsten T5".
BTW, were you expecting more than one workaround? There was just the one
there.

Incidentally, this software working correctly and integrating with
Kontact is one of the major things that kept me from moving to Linux
sooner. PDA sync is one of those things that lagged for a long time. I
remember running earlier releases (I think I ran a couple of pre 1.0
releases) and things have come along way. There are very few things,
compared to PalmDesktop (which is a POS, BTW) that work worse in
kpilot/kontact now. Thanks!

- --
 ---- _  _ _  _ ___  _  _  _
 |Y#| |  | |\/| |  \ |\ |  | |Ryan Novosielski - Systems Programmer III
 |$&| |__| |  | |__/ | \| _| |novosirj at umdnj.edu - 973/972.0922 (2-0922)
 \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF4JJRmb+gadEcsb4RApdbAJwMB9CIF3hbfS6Grg9a9IaockBXFQCglarZ
WzBThA2M4wmjQ6xUSPbzsBU=
=5tRz
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: novosirj.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20070224/79b5e008/attachment.vcf>
-------------- next part --------------
_______________________________________________
kde-pim mailing list
kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/