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

[Ryan Novosielski]

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

Jason 'vanRijn' Kasper wrote:
> Well...   actually, I'd like to get to that level of sophistication where the 
> user would have a list of choices for what they sync with, and allow them to 
> have more than one too, i.e. "USB", "Bluetooth", etc., and have kpilot be 
> smart enough to figure it out on its own.  But we're a ways from that, I 
> fear.  And as you can see, even if we have a smart user and a well-behaved 
> device and OS, we still get it wrong.  =:(

That's a nice dream in any case. Seems to me it wouldn't be SO hard,
except for the timing for a HotSync. I guess it could listen in both
places though like the Windoze one does. <shrug> Sounds nice!

>> 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.
> 
> Are you using libusb (i.e. the "usb:" device) or the "net:any" device?  If so, 
> then this is why you're seeing this.  The thing is--kpilotDaemon is doing 
> just fine, but it's blocking in its device comm loop and kpilot (and dcop) 
> are unable to communicate with it since it's blocking the main GUI event 
> loop.  This is being addressed in the next release.  If you're feeling 
> adventurous, I'd love some help in testing it to make sure I haven't broken 
> anything along the way.  =:)  

I have never used usb:, but net:any is what gets used for BlueTooth,
correct? Is there a similar workaround for BlueTooth (using a real
device... /dev/rfcomm0 maybe?). I would like to test it, but I'm not
entirely sure where to get it from... more below.

>> 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.
> 
> Glad to hear it's working.  =:)  Now I'm even more requesting your help in 
> testing out the development release of kpilot, though.  I don't have any 
> devices that require this workaround so I can't make sure that my threading 
> issues (see above) have not adversely affected this usb workaround stuff.  
> Would you be willing to try the development branch of kpilot 
> (/branches/work/kdepim-3.5.5+/kpilot) and validating this?

Sure. I'm assuming this would be an SVN checkout... But I'm not sure
from where. I see anon.kde.org is listed on the KDEPIM homepage, but I
don't think that your directory structure there matches it. Is /branches
off the root? Can I build this whole thing in my homedir after I've
checked it out and stay away from my system files? Breaking something
that currently works is a concern for me (you know how these packages
can get confused sometimes).

>>> 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.
> 
> That's a good question.  =:)  Here's what I think:
> 
> - kpilotDaemon goes into a loop where he tries to open and bind to a port.
> - he sets a QSocketNotifier that informs him when it's okay to start syncing.
> - if the socket notifier alerts him, he tries to listen and then accept the 
> palm device
> - if he makes it into the acceptDevice method and fails, he gets stuck and 
> doesn't try to restart the communication.  
> 
> I think this is what you're hitting.  The socket notifier will (I think) tell 
> him that he has data available to read from the socket, even though it's 
> not "sync data", but rather something else.  The socket notifier doesn't 
> differentiate between the two.

Sounds about right. It did appear as if the USB comm, even though it was
not for data, was the thing fouling it all up.

> The USB workaround flag causes kpilotDaemon to set another timer, and if it 
> goes off before the final steps of the device handshake occurs, it shuts down 
> the loop and starts it up again so that it doesn't hang up the kernel device 
> or the communication attempt.

Ah. Thanks for the explanation! I suspect (as it appears someone has
confirmed in the thread) that this is the "new" way of doing things for
Palm, and I'd expect future devices (680, 750, etc.) to keep this up. It
appears to be a side effect of supporting USB charging (my Tungsten E
did USB charging but never admitted it, and didn't show charging on the
menu bar -- you'd plug it in overnight and miraculously have more
battert than before).

>>> 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.
> 
> Bummer.  It would be the wrong answer anyway.

Agreed -- much more of a workaround than a fix.

> Well, actually, that flag will probably be going away.  In the development 
> branch, it has no use as far as I can tell, since I've reworked the device 
> communications layer.  It should always Just Work (TM) now.  This is what I'd 
> really appreciate your help in validating, again.  =:)

No problem. As soon as you let me know a little about how to get in
(I've used SVN once or twice, and actually support a repo install at
work, but never really use it myself -- an example co URI would be a
help to me).

>> 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!
> 
> Um.  =:)  Yeah, the earlier versions of kpilot were really problematic.  
> Reinhold and Adriaan stepped in and brought it up to a really good level of 
> usability and quality.  =:)  I'm not sure if you were trying to say that 
> there's few things that are worse than kpilot now (which would be a bad 
> thing) or that we're doing a good job and kpilot is getting better (which 
> would be a good thing)?  =:D

There are very few, if any, tasks that work well in Palm Desktop that
work poorly in kPilot is what I was trying to say -- featurewise, they
are very comparable these days. I miss photo support to an extent, but
that's only because saving photos to my card with GIMP seems to generate
strangely interlaced garbage.

> Heh.  Anyway, I'm very glad to hear that you're able to sync now.  I'd really 
> appreciate your help in validating that I've not broken the thing that allows 
> you to sync.  =:)
> 
> Thanks Ryan!!

No problem -- glad to contribute, especially since I will own stuff like
this for quite awhile (and suddenly own a brand new machine that
supports all this kinda BT/USB stuff and is fast enough to compile stuff
over and over).

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

iD8DBQFF4zAqmb+gadEcsb4RAjZxAJ9PyVdED4JsKqHHctWSP4ZRhgUlugCgvcEX
N7HiG84dejdw9uHNOUY1I10=
=p7xd
-----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/20070226/3e5b561e/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/