On Thu, Mar 01, 2007 at 08:54:16PM -0800, troy engel wrote:
> Well, you know -- I try to at least save face first to make sure it
> wasn't me doing something really stupid. :) I just happened to have
> run out of free time this week.

That's understandable. :-)


> >Could both you and Miles send me the output from "btool -lv" after a 
> >successful
> >bcharge run?  Also, please attach "lsusb -v" for your Pearl, just to make
> >sure it is using Product ID 0004, and has two interfaces.
> 
> Attached, te_lsusbv.txt and te_btoollv_4.txt (for id 4). As Miles
> indicated, I also get no devices found.

My earlier reply hasn't shown up on the mailing list yet... maybe it
got stuck.

Anyway, looks like the problem is that the device is reporting 2 in
bNumInterfaces, and then only giving one, or Linux is only seeing one.
So during device discovery, there was a (rather quiet) error in usbwrap.cc
and the whole configuration wasn't detected.

Here's a quickie patch for version 0.6 for those not using CVS.  CVS
contains full comments and better error reporting.


diff -ruN barry-0.6-orig/src/usbwrap.cc barry-0.6/src/usbwrap.cc
--- barry-0.6-orig/src/usbwrap.cc       2007-02-10 15:42:31.000000000 -0500
+++ barry-0.6/src/usbwrap.cc    2007-03-02 17:18:40.000000000 -0500
@@ -295,7 +295,7 @@
 bool InterfaceDiscovery::DiscoverInterface(struct usb_interface *interface)
 {
        if( !interface->altsetting )
-               return false;
+               return true;
 
        for( int i = 0; i < interface->num_altsetting; i++ ) {
                // load descriptor


This should fix things for both yours and Miles' Pearl devices.


> Attached, te_btoollv_1.txt. As per my previous email, there's a logic
> flaw in bcharge; if it's already been run and adjusted the USB port to
> 0x0004, when you run it a second time it fails to see the device (as
> it's looking for 0x0006). I just filed a bug. :)
>
> In order to get that output (and my device is found, so 0x0001 works)
> I altered my udev rule to be 'bcharge -o' then unplugged/replugged the
> Pearl. This has an undesired side effect -- the USB Mass Storage
> interface is *not* exposed like with 0x0004; I have my Pearl set to
> Prompt (not automount), and that dialog no longer appears with 0x0001
> and I don't get a USB disk.

Yes, this is what is supposed to happen on Product ID 0001.  As such,
I assume that this mode will be rarely used for Pearl users, once
Barry support Pearls more solidly... which the above patch should do. :-)

Thanks for your testing,
- Chris


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel

Reply via email to