[Kde-pim] Palm Treo 700p redux

Sun Dec 16 18:36:30 GMT 2007

On Sun, 16 Dec 2007 12:19:10 -0500 "Jason 'vanRijn' Kasper" 
<vr at movingparts.net> wrote:
>On 11/15/07, Ryan Novosielski <novosirj at umdnj.edu> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello developers,
>
>Hi Ryan.  Very sorry to have taken so long to get back to you.  Real Life
>(TM) has totally consumed me for the last 2+ months, so I'm just now
>catching up on kde* mailing lists.
>
>A couple of things about KPilot that confound me, and are reproducible.
>> Now that I have a little more time and some decent equipment, it'd be
>> nice to start helping out again.
>
>I would love the help!!  =:)

Then I think we shall get cracking. I have access to a relatively wide 
range of devices (III, IIIxe, V, VII, T|E, 600, 650, 700p, 755, T5 and a Tx 
if I'm not mistaken). Some of them I'd need to borrow briefly and return, 
but provided I can restore them with an NVBackup, I should be OK. Most are 
unencumbered, however. Some I would be able to lend you outright, though I 
suspect those already work.

>I have a Treo 700p, and the Zire/T5/etc. workaround had worked pretty
>> well for this particular device... two problems though:
>
>Yeah.  I broke that a while ago with the set of changes that made it
>possible to use libusb and bluetooth.  *sigh* Fix one thing, break
>another...  The problem is that just about every Palm device is different
>from the previous in slight, devastating, quirky ways.  The good news is
>that now I have a 700p myself (previously used a 650 for ~ 2 years), and so
>now I see first hand the connection problems you're talking about.    =:)

Do libusb and bluetooth now work right then? I suspect not or you might 
have offered that as a solution. :-P

>1) After a sync, or an attempted sync, KPilotDaemon holds onto the USB
>> port. This means that since my device is one that drops the USB
>> connection when switching from sync mode to draw-power mode, it will
>> lose ttyUSB1 (the one that it uses) and move to ttyUSB3 when it
>> reconnects. Here's how it goes down:
>
>Yep, you're absolutely right.  I'm seeing the same thing here.  I think I
>know what the problem is and I just need to find the time to sit down and
>hack it into submission.

Good luck! :-)

>21:57:02 HotSync Completed.
>> 21:57:02 Next HotSync will be: HotSync. Please press the HotSync button.
>> 21:57:12 Trying to open device /dev/ttyUSB1...
>> 21:57:23 Cannot accept Pilot (Success)
>> 21:57:23 Could not open device: /dev/ttyUSB1 (will retry)
>> 21:57:36 Cannot accept Pilot (No such process)
>> 21:57:48 Cannot accept Pilot (No such process)
>> 21:58:00 Cannot accept Pilot (No such process)
>>
>> ...and the progress bar is at 10%. At this point, any attempt to sync
>> will fail since KPilot has ttyUSB1 open and the phone cannot use it.
>
>Correct.  =:(
>
>In fact, the only way to solve it appears to be to cause KPilot to hold
>> open ttyUSB1 as I was describing, and let the phone return to the
>> charging state. The phone will be using ttyUSB3. I then close and reopen
>> KPilot, that tries to connect to ttyUSB1 and fails and says it will
>> retry later because it's likely a USB device. Doing a HotSync then
>> causes the device to drop its connection and go back to USB1, which then
>> works. Doing this any other way causes KPilot to try to sync right away
>> when the phone is just charging (and not going to exchange any data),
>> which then gets in the way of a real sync.
>
>Yep.  Actually, a running KPilot can be forced to drop the connection it's
>holding on to by clicking the "reset the device connection" button in
>kpilot's GUI.  And unfortunately, it takes ~ 30 seconds for kpilot to
>forcibly kill off its device comm thread.  I'll be looking into fixing that
>too.  =:/

Good to know. I mean, hey, if I can sync at all, I'm happy, but it sure 
would be great if those that cannot really hack it don't have to do the 
song and dance. :-)

>2) I've now accidentally blanked my Treo twice. I don't know this is
>> because I'm a troublemaker (quite possible), but it really should NOT
>> happen. This appears to be the way that it happens:
>>
>> a) I select "Copy Handheld to PC", knowing full well that I've just
>> cleaned up the stuff on my PC is either undesirable (very out of date --
>> so out of date that I may have formatted the phone since) or removed
>> entirely (I may have decided that I wanted to just start with the
>> Handheld data since I haven't been using KPilot).
>> b) KPilot sees that the Last PC is not this PC (standard if I had not
>> been using KPilot, since if I had any sense, I would have been backing
>> it up someplace -- in this case, my Windows PC at work), and since the
>> box regarding "Do full sync when changing PC's" is checked, it does not
>> do what I asked it to do (instead opting for a full sync).
>
>Yeah, you're right, that's a problem.   I think the decision tree gives
>precedence to full sync over copyxxtoxx.  =:/

That definitely needs to get fixed. Copy-to is a very deliberate action and 
when one knows that, absolutely, no data on the originating side should be 
touched, it's a data-loss issue. It would certainly be good, for the same 
reason, to make sure that KPilot asks about overwriting the destination 
data. Right now, I believe you don't find out until it happens.

>c) Magic happens (I'm not sure WHY a full sync even with a blank PC
>> should cause the Handheld to become blank -- it didn't get the contacts
>> since I cancelled prior to some other happenings... not sure if it would
>> have blanked the whole phone).
>> d) My phone has no appointments and no to do's.
>
>Hm.  You're right, that shouldn't happen.  In the 3+ years of using KPilot,
>I've never once hit that myself.  =:(
>
>Sorry?

No problem -- I've been very careful since... But I'd love to fix it, for 
obvious reasons. My girlfriend, BTW, has hit similar problems (did a sync 
-- she only has one computer -- and for whatever reason, recent additions 
vanished. Very bad.)

>I now have an SD card, so I can backup my phone whenever I want. I'd
>> like to see if I can't figure out why both of these things are happening
>> and if there is any way around either one (I know the second one
>> wouldn't likely happen in everyday use, but it's good to avoid cases
>> like this where an odd circumstance will blow away your data).
>
>I would LOVE your help.  =:)  I idle in #kpilot on freenode irc constantly.
>If you need help getting started in tracking this down, please stop by and
>see me.  And I would LOVE any code patches that you could provide.  =:)

I will go there as soon as I'm able. I really need to get involved before I 
forget all of the specifics. I'd also like to make sure my girlfriend 
doesn't lose data, because she is less savvy and has fewer backup resources.

>[ignoring KMail problems which I know nothing of...  =;)]

I've lost mail, had mail re-ordered, and all sorts of other screwy things 
(my mail also takes like 20 mins to finish loading for whatever reason). 
I'd love to use the whole Kontact suite, but, I can't be losing my real 
data. For that reason, it's been sandbox only.

>Thanks Ryan!!

Thank you as well, Jason. I know coming up with software like this or 
maintaining it can be a hassle (especially without access to the specs of 
the devices, and or in most cases, the devices themselves).

>-- 
>-[ Jason 'vanRijn' Kasper    //  http://movingparts.net ]-
>-[ KDE PIM Developer         //  http://www.kde.org  ]-
>-[ bash fun -> :(){ :|:&};:  //  Numbers 6:22-26 ]-
>_______________________________________________
>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/

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