On Tue, 2006-26-09 at 18:33 +0000, Daniel Holbach wrote: > Thanks a lot for all the detail and investigation. To me it looks a bit > like bug 62310 which I forwarded to: > http://bugzilla.gnome.org/show_bug.cgi?id=357762 - do you gree? > > yes, that looks about right. this bug doesn't show all the behaviour I was noticing -- there's this wierd disconnecting/establishing new ttyUSB devices -- but that might be specific to the way the tx connects. cf. this response from David Desrosiers on gnome-pilot-list (pasted in at the end of this message.
> Scott, what do you think about comment 3, specifically: > """ > - added blacklist-palm to /etc/modprobe.d, with "blacklist visor". I > cna confirm that this works -- without this line, the visor module loads > and generates /dev/ttyUSB0/1 (or sometimes 2/3, which is of course > problematic), while with it, usbserial loads by itself and that's > that. > - added 60-libpisock.rules to /etc/udev/rules.d > - added the /proc/bus/usb rule to /etc/fstab > """ > would love to hear what scott thinks... > From: > David A. Desrosiers > <[EMAIL PROTECTED]> > Reply-To: > The PalmOS< tm> integration > pacakge > <gnome-pilot-list@gnome.org> > To: > The PalmOS< tm> integration > pacakge > <gnome-pilot-list@gnome.org> > Subject: > Re: [Bug 45986] Re: unable to bind > to pilot > Date: > Tue, 26 Sep 2006 13:55:32 > -0400 > > > 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. > -- unable to bind to pilot https://launchpad.net/bugs/45986 -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
