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&lt; tm&gt; integration
> pacakge
> <gnome-pilot-list@gnome.org>
>                                To: 
> The PalmOS&lt; tm&gt; 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

Reply via email to