> > 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're simply connecting the cable to your Palm and doing nothing else, and the kernel detects a new device, wakes up and loads the visor module... that's a problem. > > 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) Well, if we can stop your TX from doing that initial "Hello, I'm here!" wakeup when it is first plugged in, that might help. I've heard LifeDrive users say that they plug it in, unplug it and then plug it in again a few seconds later to "trick" the hardware into synchronizing, but that's not really a fix I'd like to recommend. > 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? Foul things up? Definitely not, unless we uncover some other oddity that your TX exhibits that the other Palm devices do not. I'd recommend Bluetooth if you can get that working properly. > 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. The hardware in the Palm is what is initiating the disconnect/reconnect sequence, and the Linux kernel is responding to those requests. Whatever the kernel provides, is what pilot-link uses (visor, udev, libusb interfaces, etc.) Perhaps more debugging might show a sequence of bytes that forces the TX out of "Drive Mode" and into HotSync mode without the uncable/uncradle requirement. I can't be sure though, and certainly not remotely ;) Try following the Bluetooth HOWTO and see where that gets you. The Network HotSync HOWTO needs to be updated, and the others probably need to be brought to current, but since Palm hasn't really released a remarkably new device in a few years, the basics are still the same. -- David A. Desrosiers desrod gnu-designs com http://gnu-designs.com "Erosion of civil liberties... is a threat to national security."
Attachment:
signature.asc
Description: This is a digitally signed message part