Re: Problems with file conduit and Treo 680

[Adam C Powell IV <hazelsct debian org>]

On Sun, 2007-09-23 at 22:20 -0400, David A. Desrosiers wrote:
> On Sun, 2007-09-23 at 18:44 -0400, Adam C Powell IV wrote:
> > Then I do "gdb pilot-xfer" and "run -p usb: -l", wait a bit, and again
> > the pilot-xfer process goes to max CPU.  Hmm, oh well, no debugging
> > symbols, this is Debian. :-(
> 
> > I can try rebuilding pilot-link with dh_strip removed, but don't have
> > time now.  Does the strace output help?
> 
> You're dealing with the latest pilot-link version in CVS, yes? Because
> there are quite a few post-release fixes that have been dropped in that
> may alleviate some of the issues you're seeing.

No, an older version.  Thanks, I'll try CVS when I get a chance.

> As for the timing issue, that's a bit more complicated than I think we
> can solve entirely in userland. Since the physical device presents
> itself as a different entity on the usb subsystem before any kernel
> driver can be loaded (or not loaded), pilot-link has to just wait until
> something it understands (i.e. the visor driver, or the right usb
> interface presented via libusb) exists before it can communicate with
> it.

Makes sense, though it seems there should be a way to poll the USB
subsystem looking for a new connection which might be the device.

> If the device is sitting on the cable with a mount-point mapped to it
> (i.e. "Drive Mode" through uhci_hcd, for example, vs. the visor driver),
> there is little pilot-link can do to kick it out of drive mode and put
> it back into "I'm a Palm now" mode. 
> 
> It may be some magical (publicly undocumented, of course) DLP command,
> or it may be something much uglier (start the communication, kill the
> socket, try again)... I'm not really sure how this process works on
> Windows, because the USBport.dll file that contains this info, does not
> have any source available for me to look at, nor is this information
> covered in the Palm/ACCESS SDK that is available to developers. 
> 
> It would be interesting though, to build the libusb support in Cygwin
> (or native libusb support in Windows), and try to get it working in the
> same way, to see if the timing issue is still a factor there or not. 
> 
> Anyone with a Windows box and some good usb sniffer software care to
> take a whack at this?

My wife's box has the Palm Desktop and usb sniffer (used to reverse
engineer file upload to an old camera with gphoto2).  When I have time,
I'll sync to my box, hard reset, and try to catch some sniffs of syncs
there.

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting using open source tools
http://www.opennovation.com/