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

Mon Feb 26 16:39:36 GMT 2007

On Saturday 24 February 2007 14:30, Ryan Novosielski wrote:
> Jason 'vanRijn' Kasper wrote:
> > Hi Ryan!!  =:)
> >
> > On Friday 23 February 2007 18:56, Ryan Novosielski wrote:
[snip]
> 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...   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.  =:(

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

Excellent.  Glad to hear this.

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

Oh--anyway, if you have to bring up the kpilot GUI, then you're correct in 
saying that you will be unable to if you're using "usb:" or "net:any".  As a 
bad workaround, change the device in kpilot's config file to "/dev/ttyUSB1" 
(or something else) and then bring up the GUI to make changes.  Again, this 
is fixed in the development branch of kpilot.

> > [snip]
[more snippage]
> 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?

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

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.

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

[snip]
> > 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.

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

> 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

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

-- 
 -[ Jason 'vanRijn' Kasper
 -[ KDEPIM Developer
 -[ 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/