libusb-devel Mailing List for libusb

> The only thing i have is a Visual Basic Script
> which can send Data to the Device. 

If you have a Windows system handy, I'd suggest that you fire up USB Snoopy
from http://home.jps.net/~koma/ and use that to snoop the USB protocol.


Cheers,
-+JLS

-- 
                                \                carpe cavy!
seagull @ aracnet.com            \
http://www.aracnet.com/~seagull   \        (seize the guinea pig!)

Hi everybody,

I´ve got a Cypress Developers Kit  3650
with a modified Firmware from Jan Axelson

The only thing i have is a Visual Basic Script
which can send Data to the Device. 

Here is the Source:
'Data to transmit
OutputReportData(0) = &HA
OutputReportData(1) = &H0

Private Sub WriteReport()
'Send data to the device.

Dim Count As Integer
Dim NumberOfBytesRead As Long
Dim NumberOfBytesToSend As Long
Dim NumberOfBytesWritten As Long
Dim ReadBuffer() As Byte
Dim SendBuffer() As Byte

'The SendBuffer array begins at 0, so subtract 1 from the number of bytes.
ReDim SendBuffer(Capabilities.OutputReportByteLength - 1)

'******************************************************
'WriteFile
'Sends a report to the device.
'Returns: success or failure.
'Requires: the handle returned by CreateFile and
'The output report byte length returned by HidP_GetCaps
'******************************************************

'The first byte is the Report ID
SendBuffer(0) = 0

'The next bytes are data
For Count = 1 To Capabilities.OutputReportByteLength - 1
    SendBuffer(Count) = OutputReportData(Count - 1)
Next Count

NumberOfBytesWritten = 0

Result = WriteFile _
    (HidDevice, _
    SendBuffer(0), _
    CLng(Capabilities.OutputReportByteLength), _
    NumberOfBytesWritten, _
    0)

I even don´t know what kind of transfer it is. But i think its 
a Control message.


Now i´ve to program the writing and reading from the device under Linux. Can
you give me any clues or 
information how i can handle this? 

Any good link/documentation welcome.

Hendrik

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net



-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net



-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net

On Thu, Jul 25, 2002, Hans Ulrich Niedermann <gp...@n-...> wrote:
> if somebody else wants to receive mails for every libusb CVS commit,
> the project admin :-) should set up the ML lib...@li... and
> we can redirect the mail there.
> 
> Currently, the mail goes to me personally, so if nobody else is
> interested in that feature, I have nothing against going on like
> that and not setting up the ML :-)

I'm interested, so I went ahead and created the list. It'll take 6-24
hours for the list to be created, so don't change anything yet.

Thanks!

JE

Hi,

if somebody else wants to receive mails for every libusb CVS commit,
the project admin :-) should set up the ML lib...@li... and
we can redirect the mail there.

Currently, the mail goes to me personally, so if nobody else is
interested in that feature, I have nothing against going on like
that and not setting up the ML :-)

Gru=DF,

Uli

I have now had two reports of core dumps under Mandrake 8.2 (both with
2.4.18 kernels): one for my Pocket Concert library, and the other for my
Nomad Jukebox library.  Both libraries use a common code base for USB device
discovery, and both are dying in the same spot.  The libipc SIGSEGV is
captured here:

   Program received signal SIGSEGV, Segmentation fault.
   ipc_discover (ipcs=0xbffef310, n=0xbffef30c) at base.c:29
   29             if ( device->descriptor.idVendor == IPC_VENDOR_ID &&

   (gdb) p device
   $4 = (struct usb_device *) 0x1031
   (gdb) p device->descriptor
   Cannot access memory at address 0x2041
   (gdb)

Now, the code at this point looks like this:

        usb_init();

        if ( usb_find_busses() ) return -1;
        if ( usb_find_devices() ) return -1;

        bus= usb_busses;
        while ( bus != NULL ) {
                device= bus->devices;
                while ( device != NULL ) {
                        if ( device->descriptor.idVendor == IPC_VENDOR_ID &&
                                device->descriptor.idProduct ==
                                IPC_PRODUCT_ID ) {

                                ipcs->device= device;
                                ipcs->dev= NULL;
                                ipcs->lid= IPC_LOWID_1;
                                ipcs->hid= IPC_HIGHID_1;
                                ipcs++;
                                (*n)++;
                        }
                        device= device->next;
                }

                bus= bus->next;
        }


This segment works fine under RedHat 7.x and FreeBSD 4.x-RELEASE builds.
Only the two Mandrake users are reporting this problem.  One is using
libusb v0.1.6a, and claims that this used to work when he was running
Mandrake 8.1.

Have I done something incorrect in my code block that is getting tickled
under Mandrake, or might there be some larger, weirder forces at work?
I am trying to get a core dump on this, though I am not optimistic about it
telling me anything useful.


Cheers,
-+JLS

-- 
                                \                carpe cavy!
seagull @ aracnet.com            \
http://www.aracnet.com/~seagull   \        (seize the guinea pig!)

It's likely the data is garbage. Whatever happens to be in memory for
that buffer. The only reason it's being printed is because the flags say
it's an OUT transfer, so USB snoopy prints it.

Atleast that's what I suspect is happening :)

JE

On Mon, Jul 22, 2002, The Surprises <the...@at...> wrote:
> I think I'm starting to figure this out..  If I totally ignore the first
> set of output data on the in-bound transfer, and only read the 'real'
> in-bound buffer in the urb coming back section , the transaction starts
> to make sense.  The 0x06 is an ack to the previous request the host made
> in URB 5.  I wonder what the initial garbage is in the urb going down
> section, maybe the entire transaction including setup PIDs etc?  I do
> see a 0x06 byte in there..
> 
> On Mon, Jul 22, 2002 at 12:32:04PM -0400, Johannes Erdfelt wrote:
> > On Mon, Jul 22, 2002, The Surprises <the...@at...> wrote:
> > > I'm scratching my head trying to understand the usbsnoopy output.  Take
> > > the following URB:
> > > 
> > > 
> > > [7615 ms]  >>>  URB 6 going down  >>> 
> > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > >   PipeHandle           = 81b2bf54 [endpoint 0x00000083]
> > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > >   TransferBufferLength = 00000040
> > >   TransferBuffer       = 00000000
> > >   TransferBufferMDL    = 81dcd4f0
> > >     00000000: 04 00 00 00 06 00 00 00 00 00 00 00 48 c1 12 00
> > >     00000010: 00 00 00 00 14 d3 12 00 4c d5 12 00 00 00 00 00
> > >     00000020: 44 d2 12 00 1c 5f 15 00 18 5f 15 00 1c 5f 15 00
> > >     00000030: 9c d2 12 00 5e 00 00 00 18 5f 15 00 10 00 00 00
> > >   UrbLink              = 00000000
> > > [7617 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81762ad0, IRQL=2
> > > [7617 ms]  <<<  URB 6 coming back  <<< 
> > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > >   PipeHandle           = 81b2bf54 [endpoint 0x00000083]
> > >   TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
> > >   TransferBufferLength = 00000001
> > >   TransferBuffer       = 00000000
> > >   TransferBufferMDL    = 81dcd4f0
> > >     00000000: 06
> > >   UrbLink              = 00000000
> > > 
> > > The way I understand it, it is a bulk transfer from device to the host on
> > > endpoint 0x83.  First with x40 bytes of data, then a 1 byte 0x06 (maybe an
> > > ack).  I don't understand why the 40 byte transfer is tagged as a
> > > TRANSFER_DIRECTION_OUT when it is being done on an input pipe.  Pipes
> > > are uni-directional, right?  All my endpoint 0x83 URBs look just like
> > > this.  Anyway, when I try to do a bulk_read of 0x40 bytes, all I get is
> > > the 0x06 ack.  I get the same behavior for the next bulk read on this
> > > endpoint as well.  I wonder if I am supposed to be ignoring the first
> > > 0x40 bytes?  Am I interpreting the usbsnoopy log incorrectly?
> > 
> > What's really strange is that it says URB 6 is an OUT transfer (host to
> > device) when it is submitted, but it's an IN transfer (device to host)
> > when it comes back.
> > 
> > I wonder if Windows fixes up the flags for applications that pass an
> > endpoint address that conflicts? Kind of like how Linux will fix up the
> > endpoint address to match the direction (via usbdevfs).
> > 
> > That's odd.
> > 
> > I guess you should just do an IN transfer of maximum 0x40 bytes.
> > 
> > JE
> > 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

The documentation explains why it doesn't work after you call usb_reset:

http://libusb.sourceforge.net/doc/function.usbreset.html

What may not be obvious is that reenumeration may take a second or two.
How long do you wait before you call usb_find_devices?

You may also be stumbling across a bug in usb_find_devices. I'll be
checking in a patch soon for it.

JE

On Mon, Jul 22, 2002, The Surprises <the...@at...> wrote:
> Through sheer luck, I figured out a way to write to the device.  If I
> issue a usb_reset to the device first, it works.  The only problem, I
> can't send a usb_reset and bulk write in the same program.  I get a 'No
> such device' error.  I have to issue the reset by itself in a seperate
> program, then run my original code.  Is there any way to reset the
> device and open it back up within the same code?  I've tried redoing
> usb_find_devices() etc but the device no longer shows up.  Any ideas?
> 
> On Sun, Jul 21, 2002 at 01:50:23PM -0400, Johannes Erdfelt wrote:
> > On Sun, Jul 21, 2002, Seagull <se...@ar...> wrote:
> > > > I commented out the set_configuration and I get the same error.
> > > 
> > > Did you rememebr to comment out usb_claim_interface(handle, 0), too?
> > 
> > This shouldn't make a difference. usb_claim_interface generates no
> > traffic on the wire and is only used for administrative purposes.
> > 
> > In fact, if you don't do it, usbdevfs will implicitily call it for you
> > the first time, but it'll print a warning in dmesg too.
> > 
> > > Also, try running your test case with strace.  The output may give some
> > > clues as what, exactly, is failing.
> > 
> > It might, but this is an odd problem.
> > 
> > JE
> > 
> 

Through sheer luck, I figured out a way to write to the device.  If I
issue a usb_reset to the device first, it works.  The only problem, I
can't send a usb_reset and bulk write in the same program.  I get a 'No
such device' error.  I have to issue the reset by itself in a seperate
program, then run my original code.  Is there any way to reset the
device and open it back up within the same code?  I've tried redoing
usb_find_devices() etc but the device no longer shows up.  Any ideas?

On Sun, Jul 21, 2002 at 01:50:23PM -0400, Johannes Erdfelt wrote:
> On Sun, Jul 21, 2002, Seagull <se...@ar...> wrote:
> > > I commented out the set_configuration and I get the same error.
> > 
> > Did you rememebr to comment out usb_claim_interface(handle, 0), too?
> 
> This shouldn't make a difference. usb_claim_interface generates no
> traffic on the wire and is only used for administrative purposes.
> 
> In fact, if you don't do it, usbdevfs will implicitily call it for you
> the first time, but it'll print a warning in dmesg too.
> 
> > Also, try running your test case with strace.  The output may give some
> > clues as what, exactly, is failing.
> 
> It might, but this is an odd problem.
> 
> JE
> 

I think I'm starting to figure this out..  If I totally ignore the first
set of output data on the in-bound transfer, and only read the 'real'
in-bound buffer in the urb coming back section , the transaction starts
to make sense.  The 0x06 is an ack to the previous request the host made
in URB 5.  I wonder what the initial garbage is in the urb going down
section, maybe the entire transaction including setup PIDs etc?  I do
see a 0x06 byte in there..

On Mon, Jul 22, 2002 at 12:32:04PM -0400, Johannes Erdfelt wrote:
> On Mon, Jul 22, 2002, The Surprises <the...@at...> wrote:
> > I'm scratching my head trying to understand the usbsnoopy output.  Take
> > the following URB:
> > 
> > 
> > [7615 ms]  >>>  URB 6 going down  >>> 
> > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> >   PipeHandle           = 81b2bf54 [endpoint 0x00000083]
> >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> >   TransferBufferLength = 00000040
> >   TransferBuffer       = 00000000
> >   TransferBufferMDL    = 81dcd4f0
> >     00000000: 04 00 00 00 06 00 00 00 00 00 00 00 48 c1 12 00
> >     00000010: 00 00 00 00 14 d3 12 00 4c d5 12 00 00 00 00 00
> >     00000020: 44 d2 12 00 1c 5f 15 00 18 5f 15 00 1c 5f 15 00
> >     00000030: 9c d2 12 00 5e 00 00 00 18 5f 15 00 10 00 00 00
> >   UrbLink              = 00000000
> > [7617 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81762ad0, IRQL=2
> > [7617 ms]  <<<  URB 6 coming back  <<< 
> > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> >   PipeHandle           = 81b2bf54 [endpoint 0x00000083]
> >   TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
> >   TransferBufferLength = 00000001
> >   TransferBuffer       = 00000000
> >   TransferBufferMDL    = 81dcd4f0
> >     00000000: 06
> >   UrbLink              = 00000000
> > 
> > The way I understand it, it is a bulk transfer from device to the host on
> > endpoint 0x83.  First with x40 bytes of data, then a 1 byte 0x06 (maybe an
> > ack).  I don't understand why the 40 byte transfer is tagged as a
> > TRANSFER_DIRECTION_OUT when it is being done on an input pipe.  Pipes
> > are uni-directional, right?  All my endpoint 0x83 URBs look just like
> > this.  Anyway, when I try to do a bulk_read of 0x40 bytes, all I get is
> > the 0x06 ack.  I get the same behavior for the next bulk read on this
> > endpoint as well.  I wonder if I am supposed to be ignoring the first
> > 0x40 bytes?  Am I interpreting the usbsnoopy log incorrectly?
> 
> What's really strange is that it says URB 6 is an OUT transfer (host to
> device) when it is submitted, but it's an IN transfer (device to host)
> when it comes back.
> 
> I wonder if Windows fixes up the flags for applications that pass an
> endpoint address that conflicts? Kind of like how Linux will fix up the
> endpoint address to match the direction (via usbdevfs).
> 
> That's odd.
> 
> I guess you should just do an IN transfer of maximum 0x40 bytes.
> 
> JE
> 

On Mon, Jul 22, 2002, The Surprises <the...@at...> wrote:
> I'm scratching my head trying to understand the usbsnoopy output.  Take
> the following URB:
> 
> 
> [7615 ms]  >>>  URB 6 going down  >>> 
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
>   PipeHandle           = 81b2bf54 [endpoint 0x00000083]
>   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
>   TransferBufferLength = 00000040
>   TransferBuffer       = 00000000
>   TransferBufferMDL    = 81dcd4f0
>     00000000: 04 00 00 00 06 00 00 00 00 00 00 00 48 c1 12 00
>     00000010: 00 00 00 00 14 d3 12 00 4c d5 12 00 00 00 00 00
>     00000020: 44 d2 12 00 1c 5f 15 00 18 5f 15 00 1c 5f 15 00
>     00000030: 9c d2 12 00 5e 00 00 00 18 5f 15 00 10 00 00 00
>   UrbLink              = 00000000
> [7617 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81762ad0, IRQL=2
> [7617 ms]  <<<  URB 6 coming back  <<< 
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
>   PipeHandle           = 81b2bf54 [endpoint 0x00000083]
>   TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
>   TransferBufferLength = 00000001
>   TransferBuffer       = 00000000
>   TransferBufferMDL    = 81dcd4f0
>     00000000: 06
>   UrbLink              = 00000000
> 
> The way I understand it, it is a bulk transfer from device to the host on
> endpoint 0x83.  First with x40 bytes of data, then a 1 byte 0x06 (maybe an
> ack).  I don't understand why the 40 byte transfer is tagged as a
> TRANSFER_DIRECTION_OUT when it is being done on an input pipe.  Pipes
> are uni-directional, right?  All my endpoint 0x83 URBs look just like
> this.  Anyway, when I try to do a bulk_read of 0x40 bytes, all I get is
> the 0x06 ack.  I get the same behavior for the next bulk read on this
> endpoint as well.  I wonder if I am supposed to be ignoring the first
> 0x40 bytes?  Am I interpreting the usbsnoopy log incorrectly?

What's really strange is that it says URB 6 is an OUT transfer (host to
device) when it is submitted, but it's an IN transfer (device to host)
when it comes back.

I wonder if Windows fixes up the flags for applications that pass an
endpoint address that conflicts? Kind of like how Linux will fix up the
endpoint address to match the direction (via usbdevfs).

That's odd.

I guess you should just do an IN transfer of maximum 0x40 bytes.

JE

On Mon, Jul 22, 2002, Bryan Kate <Bry...@me...> wrote:
> > It's very odd.
> 
> Indeed.
> 
> > 
> > Index: usbi.h
> > ===================================================================
> > RCS file: /cvsroot/libusb/libusb/usbi.h,v
> > retrieving revision 1.9
> > diff -u -u -r1.9 usbi.h
> > --- usbi.h	8 May 2002 22:50:11 -0000	1.9
> > +++ usbi.h	20 Jul 2002 19:14:43 -0000
> > @@ -21,15 +21,14 @@
> > 
> >  #define LIST_DEL(begin, ent) \
> >  	do { \
> > -	  if (ent->prev) { \
> > +	  if (ent->prev) \
> >  	    ent->prev->next = ent->next; \
> > -	    ent->prev = NULL; \
> > -	  } else \
> > +	  else \
> >  	    begin = ent->next; \
> > -	  if (ent->next) { \
> > +	  if (ent->next) \
> >  	    ent->next->prev = ent->prev; \
> > -	    ent->next = NULL; \
> > -	  } \
> > +	  ent->prev = NULL; \
> > +	  ent->next = NULL; \
> >  	} while (0)
> > 
> >  struct usb_dev_handle {
> 
> this patch appears to work, and I can say that until I do more extensive
> testing, but the first runthrough I get seems to pick up on every
> change.  Thank you so much for your help, and I will let you know if
> anything comes up with it...

Great, I'll apply the patch. Thanks for the report!

JE

On Mon, Jul 22, 2002, Bryan Kate <Bry...@me...> wrote:
> > The 1st 3 URBs are default control msgs requesting descriptors.  The
> 4th
> > urb is selecting the config.  The 5th urb is what I originally sent.
> I
> > do see the following between the 4th and 5th urb, but I believe this
> is
> > just Windows stuff that I don't have to worry about?  There is a big 7
> > second delay in there so I even tried to mirror that but it didn't
> help.
> 
> 
> I am having similar troubles, the first 4 URBs are the same as yours
> when plugged into windows, and when I try to reproduce the 5th URB as a
> bulk read or write, I just get a connection timeout...  however, in
> windows there seems to be 2 versions of the device, with and without
> "firmware loaded".  When I plug the device in initially, it will load
> the firmware as part of the windows "add new device wizard".  Should I
> be reproducing this in linux?

Absolutely. If it needs to have firmware downloaded, you'll need to do
that first.

JE

> The 1st 3 URBs are default control msgs requesting descriptors.  The
4th
> urb is selecting the config.  The 5th urb is what I originally sent.
I
> do see the following between the 4th and 5th urb, but I believe this
is
> just Windows stuff that I don't have to worry about?  There is a big 7
> second delay in there so I even tried to mirror that but it didn't
help.


I am having similar troubles, the first 4 URBs are the same as yours
when plugged into windows, and when I try to reproduce the 5th URB as a
bulk read or write, I just get a connection timeout...  however, in
windows there seems to be 2 versions of the device, with and without
"firmware loaded".  When I plug the device in initially, it will load
the firmware as part of the windows "add new device wizard".  Should I
be reproducing this in linux?

- bryan

> It's very odd.

Indeed.

>=20
> Index: usbi.h
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /cvsroot/libusb/libusb/usbi.h,v
> retrieving revision 1.9
> diff -u -u -r1.9 usbi.h
> --- usbi.h	8 May 2002 22:50:11 -0000	1.9
> +++ usbi.h	20 Jul 2002 19:14:43 -0000
> @@ -21,15 +21,14 @@
>=20
>  #define LIST_DEL(begin, ent) \
>  	do { \
> -	  if (ent->prev) { \
> +	  if (ent->prev) \
>  	    ent->prev->next =3D ent->next; \
> -	    ent->prev =3D NULL; \
> -	  } else \
> +	  else \
>  	    begin =3D ent->next; \
> -	  if (ent->next) { \
> +	  if (ent->next) \
>  	    ent->next->prev =3D ent->prev; \
> -	    ent->next =3D NULL; \
> -	  } \
> +	  ent->prev =3D NULL; \
> +	  ent->next =3D NULL; \
>  	} while (0)
>=20
>  struct usb_dev_handle {

this patch appears to work, and I can say that until I do more extensive
testing, but the first runthrough I get seems to pick up on every
change.  Thank you so much for your help, and I will let you know if
anything comes up with it...

- bryan

I'm scratching my head trying to understand the usbsnoopy output.  Take
the following URB:


[7615 ms]  >>>  URB 6 going down  >>> 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
  PipeHandle           = 81b2bf54 [endpoint 0x00000083]
  TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000040
  TransferBuffer       = 00000000
  TransferBufferMDL    = 81dcd4f0
    00000000: 04 00 00 00 06 00 00 00 00 00 00 00 48 c1 12 00
    00000010: 00 00 00 00 14 d3 12 00 4c d5 12 00 00 00 00 00
    00000020: 44 d2 12 00 1c 5f 15 00 18 5f 15 00 1c 5f 15 00
    00000030: 9c d2 12 00 5e 00 00 00 18 5f 15 00 10 00 00 00
  UrbLink              = 00000000
[7617 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81762ad0, IRQL=2
[7617 ms]  <<<  URB 6 coming back  <<< 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
  PipeHandle           = 81b2bf54 [endpoint 0x00000083]
  TransferFlags        = 00000003 (USBD_TRANSFER_DIRECTION_IN, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000001
  TransferBuffer       = 00000000
  TransferBufferMDL    = 81dcd4f0
    00000000: 06
  UrbLink              = 00000000


The way I understand it, it is a bulk transfer from device to the host on
endpoint 0x83.  First with x40 bytes of data, then a 1 byte 0x06 (maybe an
ack).  I don't understand why the 40 byte transfer is tagged as a
TRANSFER_DIRECTION_OUT when it is being done on an input pipe.  Pipes
are uni-directional, right?  All my endpoint 0x83 URBs look just like
this.  Anyway, when I try to do a bulk_read of 0x40 bytes, all I get is
the 0x06 ack.  I get the same behavior for the next bulk read on this
endpoint as well.  I wonder if I am supposed to be ignoring the first
0x40 bytes?  Am I interpreting the usbsnoopy log incorrectly?

Thanks,
Jason

On Sun, Jul 21, 2002, Bertrik Sikken <be...@zo...> wrote:
> I'm a little confused by some of the responses in recent threads.
> In one thread it is suggested that to use an USB device, I need
> to:
> 
>     usb_init();
>     usb_find_busses();
>     usb_find_devices();
> 
>     /* Iterate over devices on each bus 'til you find the device */
> 
>     usb_open(device);
>     usb_set_configuration(device, config_no);
>     usb_claim_interface(device, if_no);
>     usb_set_altinterface(device, aif_no);
> 
> while in another thread it is suggested to skip setting the
> configuration, claiming the interface or set the altinterface
> in certain cases.
> 
> What is the proper procedure?
> 
> (The device I'm working with is very simple AFAIK, one config,
> one interface and one altinterface.)

This is a tricky situation and depends on the particular device.

If you have one config, you don't need to call usb_set_configuration.

If you have one alternate setting, you don't need to call
usb_set_altinterface.

According to the spec, setting the config and the alt setting should be
fine even when you don't need to. However, in practice, not all devices
follow the specs as closely as they should.

So as a rule a thumb, I suggest that you set the config and/or the
alternate setting only when you really need to. This will ensure maximum
compatibility with as many devices as possible.

Claiming the interface is something you should always do, while it will
seem to work without calling it on all platforms, some platforms (well,
just Linux right now) might give an error the first time you try to make
a transfer to the device.

I'll update the documentation with pretty what I've explained here.

JE

Hi all,

I'm a little confused by some of the responses in recent threads.
In one thread it is suggested that to use an USB device, I need
to:

    usb_init();
    usb_find_busses();
    usb_find_devices();

    /* Iterate over devices on each bus 'til you find the device */

    usb_open(device);
    usb_set_configuration(device, config_no);
    usb_claim_interface(device, if_no);
    usb_set_altinterface(device, aif_no);

while in another thread it is suggested to skip setting the
configuration, claiming the interface or set the altinterface
in certain cases.

What is the proper procedure?

(The device I'm working with is very simple AFAIK, one config,
one interface and one altinterface.)

Kind regards,
Bertrik Sikken

I am using libusb v0.1.6a

strace just shows an ETIMEDOUT:

ioctl(3, USBDEVFS_BULK, 0xbffff900)    = -1 ETIMEDOUT (Connection timed out)


On Sun, Jul 21, 2002 at 01:51:02PM -0400, Johannes Erdfelt wrote:
> Those first 4 look fine, but I wonder what the
> IRP_MJ_INTERNAL_DEVICE_CONTROL is for?
> 
> What version of libusb are using BTW?
> 
> JE
> 
> On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > I commented out the set_configuration and I get the same error.
> > 
> > The 1st 3 URBs are default control msgs requesting descriptors.  The 4th
> > urb is selecting the config.  The 5th urb is what I originally sent.  I
> > do see the following between the 4th and 5th urb, but I believe this is
> > just Windows stuff that I don't have to worry about?  There is a big 7
> > second delay in there so I even tried to mirror that but it didn't help.
> > 
> > 
> > [108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
> > [108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
> > [108 ms] fido=81736cf0
> > [108 ms] pdx=81736da8
> > [108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
> > [108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
> > [108 ms] fido=81736cf0
> > [108 ms] pdx=81736da8
> > [108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> > [108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> > [108 ms] fido=81736cf0
> > [108 ms] pdx=81736da8
> > [164 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> > [164 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> > [164 ms] fido=81736cf0
> > [164 ms] pdx=81736da8
> > [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> > [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> > [7614 ms]  >>>  URB 5 going down  >>> 
> > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > ...
> > 
> > 
> > On Sun, Jul 21, 2002 at 12:25:22PM -0400, Johannes Erdfelt wrote:
> > > That looks about fine. Have you tried without the usb_set_configuration
> > > call?
> > > 
> > > It's not necessary since there's only one configuration and I've seen
> > > some devices that don't handle setting it again well (or multiple
> > > times).
> > > 
> > > Also, are you sure there is nothing else before the bulk transfer?
> > > 
> > > JE
> > > 
> > > On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > > > Here is the output of testusblib:
> > > > 
> > > > bus/device  idVendor/idProduct
> > > > 001/001     0000/0000
> > > > 001/035     03F0/6202
> > > >   wTotalLength:         46
> > > >   bNumInterfaces:       1
> > > >   bConfigurationValue:  1
> > > >   iConfiguration:       0
> > > >   bmAttributes:         c0h
> > > >   MaxPower:             0
> > > >     bInterfaceNumber:   0
> > > >     bAlternateSetting:  0
> > > >     bNumEndpoints:      4
> > > >     bInterfaceClass:    255
> > > >     bInterfaceSubClass: 0
> > > >     bInterfaceProtocol: 0
> > > >     iInterface:         0
> > > >       bEndpointAddress: 81h
> > > >       bmAttributes:     02h
> > > >       wMaxPacketSize:   8
> > > >       bInterval:        0
> > > >       bRefresh:         0
> > > >       bSynchAddress:    0
> > > >       bEndpointAddress: 02h
> > > >       bmAttributes:     03h
> > > >       wMaxPacketSize:   8
> > > >       bInterval:        0
> > > >       bRefresh:         0
> > > >       bSynchAddress:    0
> > > >       bEndpointAddress: 83h
> > > >       bmAttributes:     02h
> > > >       wMaxPacketSize:   64
> > > >       bInterval:        0
> > > >       bRefresh:         0
> > > >       bSynchAddress:    0
> > > >       bEndpointAddress: 04h
> > > >       bmAttributes:     02h
> > > >       wMaxPacketSize:   64
> > > >       bInterval:        0
> > > >       bRefresh:         0
> > > >       bSynchAddress:    0
> > > > 
> > > > 
> > > > On Sun, Jul 21, 2002 at 12:03:14PM -0400, Johannes Erdfelt wrote:
> > > > > On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > > > > > I am trying to figure out the protocol for my HP 215 digital camera
> > > > > > using libusb.  I am unable to get past the first bulk write.  Using
> > > > > > USBsnoopy, the following is the first write to the device:
> > > > > > 
> > > > > > [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> > > > > > [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> > > > > > [7614 ms]  >>>  URB 5 going down  >>> 
> > > > > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > > > > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > > > > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > > > > >   TransferBufferLength = 00000008
> > > > > >   TransferBuffer       = 00000000
> > > > > >   TransferBufferMDL    = 81dcd4f0
> > > > > >     00000000: 02 ce 80 8a 84 8d 83 03
> > > > > >   UrbLink              = 00000000
> > > > > > [7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
> > > > > > [7615 ms]  <<<  URB 5 coming back  <<< 
> > > > > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > > > > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > > > > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > > > > >   TransferBufferLength = 00000008
> > > > > >   TransferBuffer       = 00000000
> > > > > >   TransferBufferMDL    = 81dcd4f0
> > > > > >   UrbLink              = 00000000
> > > > > > 
> > > > > > Here is what I am trying to do:
> > > > > > 
> > > > > > handle = usb_open (dev);
> > > > > > usb_set_configuration(handle, 1);
> > > > > > usb_claim_interface(handle, 0);
> > > > > > usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
> > > > > > 1000);
> > > > > > 
> > > > > > I get the following error:
> > > > > > USB error: error writing to bulk endpoint 4: Connection timed out
> > > > > > 
> > > > > > /var/log/messages reveals:
> > > > > > usb-uhci.c: interrupt, status 3, frame# 679
> > > > > > usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110
> > > > > > 
> > > > > > I'm running Linux 2.4.18-3
> > > > > 
> > > > > That looks about right. Are you sure you need to change the
> > > > > configuration? Do you need to change the alternate setting too?
> > > > > 
> > > > > Can you perhaps give us a dump of the descriptors for the device?
> > > > > 
> > > > > JE
> > > > > 
> > > > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Libusb-devel mailing list
> > Lib...@li...
> > https://lists.sourceforge.net/lists/listinfo/libusb-devel

Those first 4 look fine, but I wonder what the
IRP_MJ_INTERNAL_DEVICE_CONTROL is for?

What version of libusb are using BTW?

JE

On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> I commented out the set_configuration and I get the same error.
> 
> The 1st 3 URBs are default control msgs requesting descriptors.  The 4th
> urb is selecting the config.  The 5th urb is what I originally sent.  I
> do see the following between the 4th and 5th urb, but I believe this is
> just Windows stuff that I don't have to worry about?  There is a big 7
> second delay in there so I even tried to mirror that but it didn't help.
> 
> 
> [108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
> [108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
> [108 ms] fido=81736cf0
> [108 ms] pdx=81736da8
> [108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
> [108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
> [108 ms] fido=81736cf0
> [108 ms] pdx=81736da8
> [108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> [108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> [108 ms] fido=81736cf0
> [108 ms] pdx=81736da8
> [164 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> [164 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
> [164 ms] fido=81736cf0
> [164 ms] pdx=81736da8
> [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> [7614 ms]  >>>  URB 5 going down  >>> 
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> ...
> 
> 
> On Sun, Jul 21, 2002 at 12:25:22PM -0400, Johannes Erdfelt wrote:
> > That looks about fine. Have you tried without the usb_set_configuration
> > call?
> > 
> > It's not necessary since there's only one configuration and I've seen
> > some devices that don't handle setting it again well (or multiple
> > times).
> > 
> > Also, are you sure there is nothing else before the bulk transfer?
> > 
> > JE
> > 
> > On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > > Here is the output of testusblib:
> > > 
> > > bus/device  idVendor/idProduct
> > > 001/001     0000/0000
> > > 001/035     03F0/6202
> > >   wTotalLength:         46
> > >   bNumInterfaces:       1
> > >   bConfigurationValue:  1
> > >   iConfiguration:       0
> > >   bmAttributes:         c0h
> > >   MaxPower:             0
> > >     bInterfaceNumber:   0
> > >     bAlternateSetting:  0
> > >     bNumEndpoints:      4
> > >     bInterfaceClass:    255
> > >     bInterfaceSubClass: 0
> > >     bInterfaceProtocol: 0
> > >     iInterface:         0
> > >       bEndpointAddress: 81h
> > >       bmAttributes:     02h
> > >       wMaxPacketSize:   8
> > >       bInterval:        0
> > >       bRefresh:         0
> > >       bSynchAddress:    0
> > >       bEndpointAddress: 02h
> > >       bmAttributes:     03h
> > >       wMaxPacketSize:   8
> > >       bInterval:        0
> > >       bRefresh:         0
> > >       bSynchAddress:    0
> > >       bEndpointAddress: 83h
> > >       bmAttributes:     02h
> > >       wMaxPacketSize:   64
> > >       bInterval:        0
> > >       bRefresh:         0
> > >       bSynchAddress:    0
> > >       bEndpointAddress: 04h
> > >       bmAttributes:     02h
> > >       wMaxPacketSize:   64
> > >       bInterval:        0
> > >       bRefresh:         0
> > >       bSynchAddress:    0
> > > 
> > > 
> > > On Sun, Jul 21, 2002 at 12:03:14PM -0400, Johannes Erdfelt wrote:
> > > > On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > > > > I am trying to figure out the protocol for my HP 215 digital camera
> > > > > using libusb.  I am unable to get past the first bulk write.  Using
> > > > > USBsnoopy, the following is the first write to the device:
> > > > > 
> > > > > [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> > > > > [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> > > > > [7614 ms]  >>>  URB 5 going down  >>> 
> > > > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > > > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > > > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > > > >   TransferBufferLength = 00000008
> > > > >   TransferBuffer       = 00000000
> > > > >   TransferBufferMDL    = 81dcd4f0
> > > > >     00000000: 02 ce 80 8a 84 8d 83 03
> > > > >   UrbLink              = 00000000
> > > > > [7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
> > > > > [7615 ms]  <<<  URB 5 coming back  <<< 
> > > > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > > > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > > > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > > > >   TransferBufferLength = 00000008
> > > > >   TransferBuffer       = 00000000
> > > > >   TransferBufferMDL    = 81dcd4f0
> > > > >   UrbLink              = 00000000
> > > > > 
> > > > > Here is what I am trying to do:
> > > > > 
> > > > > handle = usb_open (dev);
> > > > > usb_set_configuration(handle, 1);
> > > > > usb_claim_interface(handle, 0);
> > > > > usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
> > > > > 1000);
> > > > > 
> > > > > I get the following error:
> > > > > USB error: error writing to bulk endpoint 4: Connection timed out
> > > > > 
> > > > > /var/log/messages reveals:
> > > > > usb-uhci.c: interrupt, status 3, frame# 679
> > > > > usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110
> > > > > 
> > > > > I'm running Linux 2.4.18-3
> > > > 
> > > > That looks about right. Are you sure you need to change the
> > > > configuration? Do you need to change the alternate setting too?
> > > > 
> > > > Can you perhaps give us a dump of the descriptors for the device?
> > > > 
> > > > JE
> > > > 
> > > 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

> I commented out the set_configuration and I get the same error.

Did you rememebr to comment out usb_claim_interface(handle, 0), too?

Also, try running your test case with strace.  The output may give some
clues as what, exactly, is failing.


Cheers,
John

-- 
                                \                carpe cavy!
seagull @ aracnet.com            \
http://www.aracnet.com/~seagull   \        (seize the guinea pig!)

I commented out the set_configuration and I get the same error.

The 1st 3 URBs are default control msgs requesting descriptors.  The 4th
urb is selecting the config.  The 5th urb is what I originally sent.  I
do see the following between the 4th and 5th urb, but I believe this is
just Windows stuff that I don't have to worry about?  There is a big 7
second delay in there so I even tried to mirror that but it didn't help.


[108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
[108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_CAPABILITIES)
[108 ms] fido=81736cf0
[108 ms] pdx=81736da8
[108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
[108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_PNP_DEVICE_STATE)
[108 ms] fido=81736cf0
[108 ms] pdx=81736da8
[108 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[108 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[108 ms] fido=81736cf0
[108 ms] pdx=81736da8
[164 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[164 ms] UsbSnoop - MyDispatchPNP(f88b0e00) : IRP_MJ_PNP (IRP_MN_QUERY_DEVICE_RELATIONS)
[164 ms] fido=81736cf0
[164 ms] pdx=81736da8
[7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
[7614 ms]  >>>  URB 5 going down  >>> 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
...


On Sun, Jul 21, 2002 at 12:25:22PM -0400, Johannes Erdfelt wrote:
> That looks about fine. Have you tried without the usb_set_configuration
> call?
> 
> It's not necessary since there's only one configuration and I've seen
> some devices that don't handle setting it again well (or multiple
> times).
> 
> Also, are you sure there is nothing else before the bulk transfer?
> 
> JE
> 
> On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > Here is the output of testusblib:
> > 
> > bus/device  idVendor/idProduct
> > 001/001     0000/0000
> > 001/035     03F0/6202
> >   wTotalLength:         46
> >   bNumInterfaces:       1
> >   bConfigurationValue:  1
> >   iConfiguration:       0
> >   bmAttributes:         c0h
> >   MaxPower:             0
> >     bInterfaceNumber:   0
> >     bAlternateSetting:  0
> >     bNumEndpoints:      4
> >     bInterfaceClass:    255
> >     bInterfaceSubClass: 0
> >     bInterfaceProtocol: 0
> >     iInterface:         0
> >       bEndpointAddress: 81h
> >       bmAttributes:     02h
> >       wMaxPacketSize:   8
> >       bInterval:        0
> >       bRefresh:         0
> >       bSynchAddress:    0
> >       bEndpointAddress: 02h
> >       bmAttributes:     03h
> >       wMaxPacketSize:   8
> >       bInterval:        0
> >       bRefresh:         0
> >       bSynchAddress:    0
> >       bEndpointAddress: 83h
> >       bmAttributes:     02h
> >       wMaxPacketSize:   64
> >       bInterval:        0
> >       bRefresh:         0
> >       bSynchAddress:    0
> >       bEndpointAddress: 04h
> >       bmAttributes:     02h
> >       wMaxPacketSize:   64
> >       bInterval:        0
> >       bRefresh:         0
> >       bSynchAddress:    0
> > 
> > 
> > On Sun, Jul 21, 2002 at 12:03:14PM -0400, Johannes Erdfelt wrote:
> > > On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > > > I am trying to figure out the protocol for my HP 215 digital camera
> > > > using libusb.  I am unable to get past the first bulk write.  Using
> > > > USBsnoopy, the following is the first write to the device:
> > > > 
> > > > [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> > > > [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> > > > [7614 ms]  >>>  URB 5 going down  >>> 
> > > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > > >   TransferBufferLength = 00000008
> > > >   TransferBuffer       = 00000000
> > > >   TransferBufferMDL    = 81dcd4f0
> > > >     00000000: 02 ce 80 8a 84 8d 83 03
> > > >   UrbLink              = 00000000
> > > > [7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
> > > > [7615 ms]  <<<  URB 5 coming back  <<< 
> > > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > > >   TransferBufferLength = 00000008
> > > >   TransferBuffer       = 00000000
> > > >   TransferBufferMDL    = 81dcd4f0
> > > >   UrbLink              = 00000000
> > > > 
> > > > Here is what I am trying to do:
> > > > 
> > > > handle = usb_open (dev);
> > > > usb_set_configuration(handle, 1);
> > > > usb_claim_interface(handle, 0);
> > > > usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
> > > > 1000);
> > > > 
> > > > I get the following error:
> > > > USB error: error writing to bulk endpoint 4: Connection timed out
> > > > 
> > > > /var/log/messages reveals:
> > > > usb-uhci.c: interrupt, status 3, frame# 679
> > > > usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110
> > > > 
> > > > I'm running Linux 2.4.18-3
> > > 
> > > That looks about right. Are you sure you need to change the
> > > configuration? Do you need to change the alternate setting too?
> > > 
> > > Can you perhaps give us a dump of the descriptors for the device?
> > > 
> > > JE
> > > 
> > 

That looks about fine. Have you tried without the usb_set_configuration
call?

It's not necessary since there's only one configuration and I've seen
some devices that don't handle setting it again well (or multiple
times).

Also, are you sure there is nothing else before the bulk transfer?

JE

On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> Here is the output of testusblib:
> 
> bus/device  idVendor/idProduct
> 001/001     0000/0000
> 001/035     03F0/6202
>   wTotalLength:         46
>   bNumInterfaces:       1
>   bConfigurationValue:  1
>   iConfiguration:       0
>   bmAttributes:         c0h
>   MaxPower:             0
>     bInterfaceNumber:   0
>     bAlternateSetting:  0
>     bNumEndpoints:      4
>     bInterfaceClass:    255
>     bInterfaceSubClass: 0
>     bInterfaceProtocol: 0
>     iInterface:         0
>       bEndpointAddress: 81h
>       bmAttributes:     02h
>       wMaxPacketSize:   8
>       bInterval:        0
>       bRefresh:         0
>       bSynchAddress:    0
>       bEndpointAddress: 02h
>       bmAttributes:     03h
>       wMaxPacketSize:   8
>       bInterval:        0
>       bRefresh:         0
>       bSynchAddress:    0
>       bEndpointAddress: 83h
>       bmAttributes:     02h
>       wMaxPacketSize:   64
>       bInterval:        0
>       bRefresh:         0
>       bSynchAddress:    0
>       bEndpointAddress: 04h
>       bmAttributes:     02h
>       wMaxPacketSize:   64
>       bInterval:        0
>       bRefresh:         0
>       bSynchAddress:    0
> 
> 
> On Sun, Jul 21, 2002 at 12:03:14PM -0400, Johannes Erdfelt wrote:
> > On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > > I am trying to figure out the protocol for my HP 215 digital camera
> > > using libusb.  I am unable to get past the first bulk write.  Using
> > > USBsnoopy, the following is the first write to the device:
> > > 
> > > [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> > > [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> > > [7614 ms]  >>>  URB 5 going down  >>> 
> > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > >   TransferBufferLength = 00000008
> > >   TransferBuffer       = 00000000
> > >   TransferBufferMDL    = 81dcd4f0
> > >     00000000: 02 ce 80 8a 84 8d 83 03
> > >   UrbLink              = 00000000
> > > [7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
> > > [7615 ms]  <<<  URB 5 coming back  <<< 
> > > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> > >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> > >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> > >   TransferBufferLength = 00000008
> > >   TransferBuffer       = 00000000
> > >   TransferBufferMDL    = 81dcd4f0
> > >   UrbLink              = 00000000
> > > 
> > > Here is what I am trying to do:
> > > 
> > > handle = usb_open (dev);
> > > usb_set_configuration(handle, 1);
> > > usb_claim_interface(handle, 0);
> > > usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
> > > 1000);
> > > 
> > > I get the following error:
> > > USB error: error writing to bulk endpoint 4: Connection timed out
> > > 
> > > /var/log/messages reveals:
> > > usb-uhci.c: interrupt, status 3, frame# 679
> > > usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110
> > > 
> > > I'm running Linux 2.4.18-3
> > 
> > That looks about right. Are you sure you need to change the
> > configuration? Do you need to change the alternate setting too?
> > 
> > Can you perhaps give us a dump of the descriptors for the device?
> > 
> > JE
> > 
> 

Here is the output of testusblib:

bus/device  idVendor/idProduct
001/001     0000/0000
001/035     03F0/6202
  wTotalLength:         46
  bNumInterfaces:       1
  bConfigurationValue:  1
  iConfiguration:       0
  bmAttributes:         c0h
  MaxPower:             0
    bInterfaceNumber:   0
    bAlternateSetting:  0
    bNumEndpoints:      4
    bInterfaceClass:    255
    bInterfaceSubClass: 0
    bInterfaceProtocol: 0
    iInterface:         0
      bEndpointAddress: 81h
      bmAttributes:     02h
      wMaxPacketSize:   8
      bInterval:        0
      bRefresh:         0
      bSynchAddress:    0
      bEndpointAddress: 02h
      bmAttributes:     03h
      wMaxPacketSize:   8
      bInterval:        0
      bRefresh:         0
      bSynchAddress:    0
      bEndpointAddress: 83h
      bmAttributes:     02h
      wMaxPacketSize:   64
      bInterval:        0
      bRefresh:         0
      bSynchAddress:    0
      bEndpointAddress: 04h
      bmAttributes:     02h
      wMaxPacketSize:   64
      bInterval:        0
      bRefresh:         0
      bSynchAddress:    0


On Sun, Jul 21, 2002 at 12:03:14PM -0400, Johannes Erdfelt wrote:
> On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> > I am trying to figure out the protocol for my HP 215 digital camera
> > using libusb.  I am unable to get past the first bulk write.  Using
> > USBsnoopy, the following is the first write to the device:
> > 
> > [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> > [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> > [7614 ms]  >>>  URB 5 going down  >>> 
> > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> >   TransferBufferLength = 00000008
> >   TransferBuffer       = 00000000
> >   TransferBufferMDL    = 81dcd4f0
> >     00000000: 02 ce 80 8a 84 8d 83 03
> >   UrbLink              = 00000000
> > [7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
> > [7615 ms]  <<<  URB 5 coming back  <<< 
> > -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
> >   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
> >   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
> >   TransferBufferLength = 00000008
> >   TransferBuffer       = 00000000
> >   TransferBufferMDL    = 81dcd4f0
> >   UrbLink              = 00000000
> > 
> > Here is what I am trying to do:
> > 
> > handle = usb_open (dev);
> > usb_set_configuration(handle, 1);
> > usb_claim_interface(handle, 0);
> > usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
> > 1000);
> > 
> > I get the following error:
> > USB error: error writing to bulk endpoint 4: Connection timed out
> > 
> > /var/log/messages reveals:
> > usb-uhci.c: interrupt, status 3, frame# 679
> > usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110
> > 
> > I'm running Linux 2.4.18-3
> 
> That looks about right. Are you sure you need to change the
> configuration? Do you need to change the alternate setting too?
> 
> Can you perhaps give us a dump of the descriptors for the device?
> 
> JE
> 

On Sun, Jul 21, 2002, The Surprises <the...@at...> wrote:
> I am trying to figure out the protocol for my HP 215 digital camera
> using libusb.  I am unable to get past the first bulk write.  Using
> USBsnoopy, the following is the first write to the device:
> 
> [7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
> [7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
> [7614 ms]  >>>  URB 5 going down  >>> 
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
>   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
>   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
>   TransferBufferLength = 00000008
>   TransferBuffer       = 00000000
>   TransferBufferMDL    = 81dcd4f0
>     00000000: 02 ce 80 8a 84 8d 83 03
>   UrbLink              = 00000000
> [7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
> [7615 ms]  <<<  URB 5 coming back  <<< 
> -- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
>   PipeHandle           = 81b2bf74 [endpoint 0x00000004]
>   TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
>   TransferBufferLength = 00000008
>   TransferBuffer       = 00000000
>   TransferBufferMDL    = 81dcd4f0
>   UrbLink              = 00000000
> 
> Here is what I am trying to do:
> 
> handle = usb_open (dev);
> usb_set_configuration(handle, 1);
> usb_claim_interface(handle, 0);
> usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
> 1000);
> 
> I get the following error:
> USB error: error writing to bulk endpoint 4: Connection timed out
> 
> /var/log/messages reveals:
> usb-uhci.c: interrupt, status 3, frame# 679
> usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110
> 
> I'm running Linux 2.4.18-3

That looks about right. Are you sure you need to change the
configuration? Do you need to change the alternate setting too?

Can you perhaps give us a dump of the descriptors for the device?

JE

I am trying to figure out the protocol for my HP 215 digital camera
using libusb.  I am unable to get past the first bulk write.  Using
USBsnoopy, the following is the first write to the device:


[7614 ms] UsbSnoop - DispatchAny(f88ae600) : IRP_MJ_INTERNAL_DEVICE_CONTROL
[7614 ms] UsbSnoop - MyDispatchInternalIOCTL(f88afe70) : fdo=8159a030, Irp=8173ab00, IRQL=0
[7614 ms]  >>>  URB 5 going down  >>> 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
  PipeHandle           = 81b2bf74 [endpoint 0x00000004]
  TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000008
  TransferBuffer       = 00000000
  TransferBufferMDL    = 81dcd4f0
    00000000: 02 ce 80 8a 84 8d 83 03
  UrbLink              = 00000000
[7615 ms] UsbSnoop - MyInternalIOCTLCompletion(f88afda0) : fido=81aa95c0, Irp=8173ab00, Context=81f0f858, IRQL=2
[7615 ms]  <<<  URB 5 coming back  <<< 
-- URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
  PipeHandle           = 81b2bf74 [endpoint 0x00000004]
  TransferFlags        = 00000002 (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK)
  TransferBufferLength = 00000008
  TransferBuffer       = 00000000
  TransferBufferMDL    = 81dcd4f0
  UrbLink              = 00000000


Here is what I am trying to do:

handle = usb_open (dev);
usb_set_configuration(handle, 1);
usb_claim_interface(handle, 0);
usb_bulk_write(handle, 0x4, "\x02\xce\x80\x8a\x84\x8d\x83\x03", 8,
1000);

I get the following error:
USB error: error writing to bulk endpoint 4: Connection timed out

/var/log/messages reveals:
usb-uhci.c: interrupt, status 3, frame# 679
usbdevfs: USBDEVFS_BULK failed dev 33 ep 0x4 len 8 ret -110

I'm running Linux 2.4.18-3

Thanks for any help!
Jason