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