Re: [Bug 45986] Re: unable to bind to pilot



Thanks David,

On Tue, 2006-26-09 at 13:55 -0400, David A. Desrosiers wrote:
> On Tue, 2006-09-26 at 13:41 -0400, Matt Price wrote:
> > Made some small diagnostic progress on this.  still no joy with the
> > libusb direct method.  However I can verify that it's possible to send
> > data across the /dev/ttyUSB* ports created by the visor module (if it's
> > not blacklisted).  pilot-xfer still won't work; in fact, as far as I
> > can tell, just starting a pilot-xfer operation on a ttyUSB port will
> > cause the palm device to detach from the port.
> 
> Let's try something... 
> 
> Just connect your TX to the USB port, but don't hit any buttons at all
> on your Palm or any desktop Palm GUI applications. Do you see any
> activity in the logs related to USB activity? 
> 

yes.  dmesg gives this (this is with the visor module un-blacklisted):

> [17180305.500000] usb 3-1: new full speed USB device using uhci_hcd and address 4
> [17180305.672000] usb 3-1: configuration #1 chosen from 1 choice
> [17180305.676000] visor 3-1:1.0: Handspring Visor / Palm OS converter detected
> [17180305.676000] usb 3-1: Handspring Visor / Palm OS converter now attached to ttyUSB2
> [17180305.676000] usb 3-1: Handspring Visor / Palm OS converter now attached to ttyUSB3
> If you do, this is a hardware problem on the Palm side, and might be
> related to the same sort of problem on the LifeDrive units. 
> 
> There is nothing we can do from the desktop side at this time to work
> around this, so you will have to uncradle and re-cradle your Palm every
> time you want to sync using these Linux tools. 
> 
could you clarify there?  That is, should I start pilot-xfer and then
plug my palm in to the sync cable (there's not 'cradle per se with the
TX)

> If that doesn't work, I'd probably consider the TX "unsupported" at this
> time. Since I don't have one myself to tinker with, I can't say for sure
> how it works or how we might be able to try to provide a software
> workaround for the issues with it.
> 
would it make sense to try an IR, bluetooth, or network (wi-fi) sync?  I
have all of these modes at my disposal in my laptop, though I've yet to
use the IR or bluetooth since I've never had need of them.  I notice
your very clear howto's on these subjects are a couple of years old --
will I foul things up by following your directions there?

> > note that the usb2/3 disconnect somehow comes right after the
> > attachment to 0/1!  I think this is somehow caused by pilot-link.
> 
> pilot-link has nothing at all to do with how hardware is detected by the
> Linux kernel. If anything, this is probably udev, sysfs or some other
> lower-level mechanism. We only use the facilities they provide to us at
> the userspace level. 

of course, sorry.  I think what I meant was, that something in the
exchange that pilot-xfer initiates leads the kernel (or udev, or
something) to disconnent and reconnect the palm.  

> > and push the sync button, the cat process immediately ends, as though
> > it's received a ctrl-c over the line or something.  
> 
> This is sounding more and more like the LifeDrive issue with its "Drive
> Mode", where its always connected even when HotSync is not pressed. The
> ^C you are asserting is probably the device latching and trying to
> reconnect (i.e. switching out of "Drive Mode" and going to HotSync
> mode). 
> 
i see.  I don't thnk the tx has a drive mode per se, though hi guess it
could be something similar.

> Again, I can't be sure. Anyone else here have a TX to verify? 
> 
> > and finally, I can now get an effect from gpilotd.  by adding several
> > new devices -- so that /dev/ttyUSB[0-3] are ALL being watched, I can
> > make my palm do a soft reset! 
> 
> Sending the wrong control data to the wrong usb endpoint will have odd
> effects like that. If you value the data on your Palm and haven't backed
> it up elsewhere, I wouldn't go playing around like that. You might find
> a condition that hard-resets the device instead, resulting in the loss
> of ALL data on the device. 
> 

well, guess I'll stop that then!


THanks,

matt
> 
> 
> _______________________________________________
> gnome-pilot-list mailing list
> gnome-pilot-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-pilot-list

Attachment: signature.asc
Description: This is a digitally signed message part



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]