libusb-devel Mailing List for libusb

I have written a program to read the scans from a metrologic barcode scanner
and output them to the screen using libusb. It worked fine a few days ago,
now all my usb_bulk_read statements are timing out. I didn't change any
settings that I know of. I did notice in the kernel logs there was a
suspictious messege I didn't remember seeing before: localhost kernel:
usbdevfs: remount parameter error . Despite this error the usb filesystem
seemed to be mounted fine in /proc/bus/usb/. I tried to use the usb-robot
utility, but was experiencing the same problems. It used to work as well.

Any help would be appreciated,
DH

here's cat /proc/bus/usb/devices:
T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.00 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB UHCI Root Hub
S:  SerialNumber=e400
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=1.5 MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0c2e ProdID=0700 Rev=9c.48
S:  Manufacturer=Metro
S:  Product=Metrologic  Scanner
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=300mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
E:  Ad=02(O) Atr=03(Int.) MxPS=   8 Ivl=10ms
E:  Ad=81(I) Atr=03(Int.) MxPS=   8 Ivl=10ms

Here's the function I'm having problems with using libusb:
int outputScans(struct usb_device * dev) {
 struct usb_dev_handle * handle;

 int stat;
    int interfaceNum;
    int altNum;
    int endPoint;
    int numBytes;
    int quit;
    int i;

    char buf[9];

 handle = usb_open(dev);
 if(handle==NULL)
  return -1;

 //This is probably redundant, but just to make sure it's set...
  stat = usb_set_configuration( handle,
dev->config[0].bConfigurationValue );
  if(stat<0)
   return -2;

  //The Interface must be claimed before use
  interfaceNum = dev->config[0].interface[0].altsetting[0].bInterfaceNumber;
  stat = usb_claim_interface(handle, interfaceNum);
  if(stat<0)
   return -3;

  //This is probably also redundant, but just to make sure...
  altNum = dev->config[0].interface[0].altsetting[0].bAlternateSetting;
  stat = usb_set_altinterface(handle, altNum);
  if(stat<0)
   return -4;


endPoint=dev->config[0].interface[0].altsetting[0].endpoint[1].bEndpointAddr
ess;

numBytes=dev->config[0].interface[0].altsetting[0].endpoint[1].wMaxPacketSiz
e;

  quit = 0;
  while ( !quit ) {
       //this is where I read from the device
       stat =  usb_bulk_read(handle, endPoint, buf, numBytes, TIMEOUT);

       //need to null terminate the c-string
       buf[8]='\0';

       //if there is a timeout and the program has been terminated
       //stop loop
       if ( stat<0 ) {
        quit = killed;
       }
       else {
        printf("%s",buf);
       }
  }

  stat = usb_release_interface(handle, interfaceNum);
  if(stat<0)
   return -5;

  usb_close( handle );

  return 0;
}

> Date: Tue, 20 May 2003 14:00:47 -0600 (MDT)
> From: Nathan Hjelm <hj...@un...>
> cc: lib...@li...
> X-UIDL: 3*6!!1@S!!W"^!!fW1e9
> 
> > So what "problems" did you run into "reading large amounts of data"?
> > For me, this code causes a timeout on a read that comes up short, and
> > an error code returned, which is different, and undesirable, behavior
> > from under Linux.
> 
> I dont really recall at this point.
> 
> > Is there any way we can make it work just like Linux?
> 
> I just added a line which should correct your problem. It breaks from the 
> loop in the event of a short read (bytes are read, but a timeout error was 
> returned from a pipe read).

No, the timeout is the problem. Under Linux, I just get back a short
buffer with no timeout.

> Let me know if this fix makes the procedure work the ways you expect.

I'll try it, but I doubt that this will help.

-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.

> So what "problems" did you run into "reading large amounts of data"?
> For me, this code causes a timeout on a read that comes up short, and
> an error code returned, which is different, and undesirable, behavior
> from under Linux.

I dont really recall at this point.

> Is there any way we can make it work just like Linux?

I just added a line which should correct your problem. It breaks from the 
loop in the event of a short read (bytes are read, but a timeout error was 
returned from a pipe read).

Let me know if this fix makes the procedure work the ways you expect.

Hello all,

Please CC me directly with any responses.
I am trying to get the HPOJ drivers working on Mac OS
X, which uses libusb.  I am stuck right now becuase I
am getting failures in darwin.c, in the usb_bulk_write
function.  
The exact error is that WritePipeAsyncTO method is
returning a value of kIOReturnVMError (0xe00002c8),
and I am not sure why.  

What happens is that the device is opened, the channel
is set (?) and a null byte gets sent (not sure why
this is desired yet), which seems to succeed, then the
nect call to write fails.

I set up debug, and added some extra prints to examine
return values, and am getting this :

usb_os_open: 03f0:0f11
usb_os_open: device opened
usb_control_msg: 193 0 78 0 0xbffff7d0 1 5000
Converting ep address to pipeRef.
Pipe 1: DIR: 0 number: 1
pipeRef for ep address 0x01 found: 0x01
usb_bulk_write: endpoint=0x01 size=1 TO=5000
successfully created event source
successfully called writepipeTo
write completed
usb_control_msg: 193 0 77 0 0xbffff7d0 1 5000
Converting ep address to pipeRef.
Pipe 1: DIR: 0 number: 1
pipeRef for ep address 0x01 found: 0x01
usb_bulk_write: endpoint=0x01 size=6 TO=5000
successfully created event source
WritePipeAsyncTo: No such file or directory
some other error, e00002c8

Any help or even direction as to what else to look at
would be greatly appreciated.

Thanks,

Tim Regovich

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've updated my applet for controlling features and getting status on various
Logitech mice. This set is mostly changes from Robert Love - thanks.

Available at http://www.frogmouth.net/logitech-applet-0.3.tar.gz

This should be portable to any OS supported by libusb, but I've only tested
 it with Linux. Send bug reports and patches if you have trouble.

I'm also working on a GUI version for KDE.

Brad
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+x1h3W6pHgIdAuOMRAqWdAJ4qdB2cVM6+x0auBese9DZVcnexWQCfdxQE
zBQ/YJQuhRjFrusMOyZtIZI=
=tpe0
-----END PGP SIGNATURE-----

On Thu, May 15, 2003, St=E9phane Grundschober <gru...@da...> wro=
te:
> I've put in the "patches" section of sf an improvement (from my point 
> of view :-) of the timeout mechanism for interrupt reads. (patch 
> against linux.c v1.41. I've seen that in the mean time there is a 
> 1.42... sorry)
> 
> Instead of using an alarm() call (where you have to use a signal 
> handler), I propose to use a non-blocking ioctl() in combination with =
a 
> sub-second timeout  (via a select() call) and real time comparison.
> 
> Ok, the process is then a little bit more "active" than before, but I 
> hate programming signal handlers...
> 
> Feedback, comments or flame are welcome!

I think this is good for 0.1

I wasn't very keen on doing signal handling in the library.

I'll fix up usb_interrupt_write in the same manner soon.

JE

cool, ill apply it

Here is the CVS diff of my fixes for libusb in Darwin. The major functional changes were:

o Select configuration and interface explicitly; this is done by Darwin
  automatically for "composite" devices.

o Revise usb_bulk_read() to work on interrupt pipes. You can't specify
  timeouts for interrupt pipes in Darwin IOKit USB. I check if the
  pipe is an interrupt pipe and treat it specially; all other kinds of
  pipes (e.g. bulk, isochronous) use the default code.

So now it should do something fairly useful for devices not of the
"composite" class, and it should work to read interrupt pipes.

The one bug I know about is on short reads. If the packet sent by the
USB device on a read is shorter than the read request, libusb willl
time out and give an error code. In Linux, the read will succeed and
return the actual number of bytes read.

NB: A "set configuration" will reset to using the first interface on
the device; I think the "claim interface" call should really occur
after "set configuration".

-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.

Index: libusb/darwin.c
===================================================================
RCS file: /cvsroot/libusb/libusb/darwin.c,v
retrieving revision 1.22
diff -r1.22 darwin.c
94,95c94,95
<   /* set up the matching dictionary for class IOUSBDevice and it's subclasses.
<    it will be consumed by the next call */
---
>   /* set up the matching dictionary for class IOUSBDevice and its subclasses.
>      It will be consumed by the next call */
147c147
<       USB_ERROR_STR(result, "Another process already has exclusive access to the device.");
---
>       USB_ERROR_STR(result, "usb_os_open: Another process already has exclusive access to the device.");
150c150
<       USB_ERROR_STR(result, "could not open device");
---
>       USB_ERROR_STR(result, "usb_os_open: could not open device");
181c181
<     USB_ERROR_STR(result, "error closing device");
---
>     USB_ERROR_STR(result, "usb_os_close: error closing device");
183c183
<   /* device may not need to be released, but if it has too... */
---
>   /* device may not need to be released, but if it has to... */
189,210c189
< int usb_set_configuration(usb_dev_handle *dev, int configuration)
< {
<   struct darwin_dev_handle *device;
<   io_return_t result;
< 
<   if (!dev)
<     USB_ERROR(-ENXIO);
< 
<   if ((device = dev->impl_info) == NULL)
<     USB_ERROR(-ENOENT);
< 
<   result = (*(device->device))->SetConfiguration(device->device, configuration);
< 
<   if (result)
<     USB_ERROR_STR(result, "could not set configuration");
< 
<   dev->config = configuration;
< 
<   return 0;
< }
< 
< int usb_claim_interface(usb_dev_handle *dev, int interface)
---
> static int claim_interface ( struct darwin_dev_handle *device, int interface )
212,213d190
<   struct darwin_dev_handle *device = dev->impl_info;
< 
220d196
< 
222c198
<   int current_interface = 0;
---
>   int current_interface;
224,235c200,203
<   request.bInterfaceClass = kIOUSBFindInterfaceDontCare;
<   request.bInterfaceSubClass = kIOUSBFindInterfaceDontCare;
<   request.bInterfaceProtocol = kIOUSBFindInterfaceDontCare;
<   request.bAlternateSetting = kIOUSBFindInterfaceDontCare;
< 
<   if (!device)
<     USB_ERROR(-ENOENT);
< 
<   if (!(device->device))
<     USB_ERROR(-EINVAL);
< 
<   (*(device->device))->CreateInterfaceIterator(device->device, &request, &interface_iterator);
---
>   result = (*(device->device))->CreateInterfaceIterator(device->device, &request, &interface_iterator);
>   if ( result ) {
>     USB_ERROR_STR ( -result, "claim_interface: CreateInterfaceIterator failed" );
>   }
237c205
<   while (current_interface++ <= interface)
---
>   for ( current_interface=0; current_interface<=interface; current_interface++ ) {
238a207,211
>     if ( usb_debug > 3 )
>       fprintf ( stderr, "Interface %d of device is 0x%x\n",
> 		current_interface, (void *)usbInterface );
>   }
>   current_interface--;
243,244c216,256
<   if (!usbInterface)
<     USB_ERROR(-ENOENT);
---
>   if (!usbInterface) {
>     UInt8 nConfig;			     /* Index of configuration to use */
>     IOUSBConfigurationDescriptorPtr configDesc; /* to describe which configuration to select */
>     /* Only a composite class device with no vendor-specific driver will
>        be configured. Otherwise, we need to do it ourselves, or there
>        will be no interfaces for the device. */
> 
>     if ( usb_debug > 3 )
>       fprintf ( stderr,"claim_interface: No interface found; selecting configuration\n" );
> 
>     result = (*(device->device))->GetNumberOfConfigurations ( device->device, &nConfig );
>     if ( result )
>       USB_ERROR_STR(result,"claim_interface: could not get number of configurations");
>     else if ( nConfig < 1 )
>       USB_ERROR_STR(kIOReturnError ,"claim_interface: no configurations for device");
>     else if ( nConfig > 1 && usb_debug > 0 )
>       fprintf ( stderr, "claim_interface: device has more than one"
> 		" configuration, using the first (warning)\n" );
> 
>     if ( usb_debug > 3 )
>       fprintf ( stderr, "claim_interface: device has %d configuration%s\n",
> 		(int)nConfig, (nConfig>1?"s":"") );
> 
>     /* Always use the first configuration */
>     result = (*(device->device))->GetConfigurationDescriptorPtr ( (device->device), 0, &configDesc );
>     if ( result ) {
>       (*(device->device))->USBDeviceClose ( (device->device) );
>       (*(device->device))->Release ( (device->device) );
>       USB_ERROR_STR(result, "claim_interface: could not get configuration descriptor");
>     }
>     else if ( usb_debug > 3 )
>       fprintf ( stderr, "claim_interface: configuration value is %d\n",
> 		configDesc->bConfigurationValue );
> 
>     result = (*(device->device))->SetConfiguration ( (device->device), configDesc->bConfigurationValue );
>     if ( result ) {
>       (*(device->device))->USBDeviceClose ( (device->device) );
>       (*(device->device))->Release ( (device->device) );
>       fprintf ( stderr, "claim_interface: result is %x\n", result );
>       USB_ERROR_STR(result, "claim_interface: could not set configuration");
>     }
246,249c258,278
<   result = IOCreatePlugInInterfaceForService(usbInterface,
< 						   kIOUSBInterfaceUserClientTypeID,
< 						   kIOCFPlugInInterfaceID,
< 						   &plugInInterface, &score);
---
>     request.bInterfaceClass = kIOUSBFindInterfaceDontCare;
>     request.bInterfaceSubClass = kIOUSBFindInterfaceDontCare;
>     request.bInterfaceProtocol = kIOUSBFindInterfaceDontCare;
>     request.bAlternateSetting = kIOUSBFindInterfaceDontCare;
> 
>     /* Now go back and get the chosen interface */
>     result = (*(device->device))->CreateInterfaceIterator(device->device, &request, &interface_iterator);
>     if ( result ) {
>       USB_ERROR_STR ( -result, "claim_interface: CreateInterfaceIterator failed" );
>     }
> 
>     for ( current_interface=0; current_interface<=interface; current_interface++ ) {
>       usbInterface = IOIteratorNext(interface_iterator);
>       if ( usb_debug > 3 )
> 	fprintf ( stderr, "claim_interface: Interface %d of device is 0x%x\n",
> 		  current_interface, (void *)usbInterface );
>     }
>     current_interface--;
> 
>     /* the interface iterator is no longer needed, release it */
>     IOObjectRelease(interface_iterator);
250a280,287
>     if (!usbInterface)
>       USB_ERROR_STR ( -ENOENT, "claim_interface: interface iterator returned NULL" );
>   }
> 
>   result = IOCreatePlugInInterfaceForService(usbInterface,
> 					     kIOUSBInterfaceUserClientTypeID,
> 					     kIOCFPlugInInterfaceID,
> 					     &plugInInterface, &score);
258,259c295,297
<                                               CFUUIDGetUUIDBytes(kIOUSBInterfaceInterfaceID),
<                                               (LPVOID) &device->interface);
---
> 					      CFUUIDGetUUIDBytes(kIOUSBInterfaceInterfaceID),
> 					      (LPVOID) &device->interface);
> 
265d302
< 
268a306,309
>   if ( usb_debug > 3 )
>     fprintf ( stderr, "claim_interface: Interface %d of device from QueryInterface is 0x%x\n",
> 	      current_interface, (void *)(device->interface) );
> 
273a315,370
>   return 0;
> }
> 
> int usb_set_configuration(usb_dev_handle *dev, int configuration)
> {
>   struct darwin_dev_handle *device;
>   io_return_t result;
> 
>   if ( usb_debug > 3 )
>     fprintf ( stderr, "usb_set_configuration: called for config %x\n", configuration );
> 
>   if (!dev)
>     USB_ERROR_STR ( -ENXIO, "usb_set_configuration: called with null device\n" );
> 
>   if ((device = dev->impl_info) == NULL)
>     USB_ERROR_STR ( -ENOENT, "usb_set_configuration: device not properly initialized" );
> 
>   /* Setting configuration will invalidate the interface, so we need
>      to reclaim it. First, dispose of existing interface, if any. */
>   if ( device->interface )
>     usb_release_interface(dev, dev->interface);
> 
>   result = (*(device->device))->SetConfiguration(device->device, configuration);
> 
>   if (result)
>     USB_ERROR_STR(result, "usb_set_configuration: could not set configuration" );
> 
>   /* Reclaim interface: assume zero */
>   result = claim_interface ( device, 0 );
>   if ( result )
>     USB_ERROR_STR ( result, "usb_set_configuration: could not reclaim interface" );
> 
>   dev->config = configuration;
> 
>   return 0;
> }
> 
> int usb_claim_interface(usb_dev_handle *dev, int interface)
> {
>   struct darwin_dev_handle *device = dev->impl_info;
> 
>   io_return_t result;
> 
>   if ( usb_debug > 3 )
>     fprintf ( stderr, "usb_claim_interface: called for interface %d\n", interface );
> 
>   if (!device)
>     USB_ERROR_STR ( -ENOENT, "usb_claim_interface: device is NULL" );
> 
>   if (!(device->device))
>     USB_ERROR_STR ( -EINVAL, "usb_claim_interface: device->device is NULL" );
> 
>   result = claim_interface ( device, interface );
>   if ( result )
>     USB_ERROR_STR ( result, "usb_claim_interface: couldn't claim interface" );
> 
276c373
<   /* interface is claimed and async IO is set up return 0 */
---
>   /* interface is claimed and async IO is set up: return 0 */
298c395
<     USB_ERROR_STR(result, "error closing interface");
---
>     USB_ERROR_STR(result, "usb_release_interface: error closing interface");
303c400
<     USB_ERROR_STR(result, "error releasing interface");
---
>     USB_ERROR_STR(result, "usb_release_interface: error releasing interface");
323c420
<     USB_ERROR_STR(-EACCES, "interface used without being claimed");
---
>     USB_ERROR_STR(-EACCES, "usb_set_altinterface: interface used without being claimed");
328c425
<     USB_ERROR_STR(result, "could not set alternate interface");
---
>     USB_ERROR_STR(result, "usb_set_altinterface: could not set alternate interface");
347c444,449
<   (*(device->interface))->GetNumEndpoints(device->interface, &numep);
---
>   ret = (*(device->interface))->GetNumEndpoints(device->interface, &numep);
>   if ( ret ) {
>     if ( usb_debug > 1 )
>       fprintf ( stderr, "ep_to_pipeRef: interface is %x\n", device->interface );
>     USB_ERROR_STR ( -ret, "ep_to_pipeRef: can't get number of endpoints for interface" );
>   }
352c454
< 					      &dont_care1, &dont_care2, &dont_care3);
---
> 						    &dont_care1, &dont_care2, &dont_care3);
355c457,458
<       fprintf (stderr, "An error occured geting Pipe information\n");
---
>       fprintf (stderr, "ep_to_pipeRef: an error occurred getting pipe information on pipe %d\n",
> 	       i );
358c461
< 	fprintf (stderr, "Interface not open for exclusive access\n");
---
> 	fprintf (stderr, "ep_to_pipeRef: Interface not open for exclusive access\n");
361c464
< 	fprintf (stderr, "No connection to IOService\n");
---
> 	fprintf (stderr, "ep_to_pipeRef: No connection to IOService\n");
364c467
< 	fprintf (stderr, "An unknown error occured\n");
---
> 	fprintf (stderr, "ep_to_pipeRef: An unknown error occured\n");
372c475
<       fprintf (stderr, "Pipe %i: DIR: %i number: %i\n", i, direction, number);
---
>       fprintf (stderr, "ep_to_pipeRef: Pipe %i: DIR: %i number: %i\n", i, direction, number);
377c480
< 	fprintf(stderr, "pipeRef for ep address 0x%02x found: 0x%02x\n", ep, i);
---
> 	fprintf(stderr, "ep_to_pipeRef: pipeRef for ep address 0x%02x found: 0x%02x\n", ep, i);
384c487
<     fprintf(stderr, "No pipeRef found with endpoint address 0x%02x.\n", ep);
---
>     fprintf(stderr, "ep_to_pipeRef: No pipeRef found with endpoint address 0x%02x.\n", ep);
417c520
<     USB_ERROR_STR(-EACCES, "interface used without being claimed");
---
>     USB_ERROR_STR(-EACCES, "usb_bulk_write: interface used without being claimed");
428c531
<   /* there seems to be no way to determine how many bytes are actually written */ 
---
>   /* there seems to be no way to determine how many bytes are actually written */
430,431c533,534
< 					    bytes, size, 0, timeout,
< 					    write_completed, NULL);
---
> 						    bytes, size, 0, timeout,
> 						    write_completed, NULL);
434c537
<     USB_ERROR_STR(result, "error writing to device");
---
>     USB_ERROR_STR(result, "usb_bulk_write: error writing to device");
453a557,559
>   UInt8				direction, number, transferType, interval;
>   UInt16				maxPacketSize;
> 
460c566
<     USB_ERROR(-ENXIO);
---
>     USB_ERROR_STR ( -ENXIO, "usb_bulk_read: called with null device" );
463c569
<     USB_ERROR(-ENOENT);
---
>     USB_ERROR_STR ( -ENOENT, "usb_bulk_read: device not initialized" );
467c573
<     USB_ERROR_STR(-EACCES, "interface used without being claimed");
---
>     USB_ERROR_STR(-EACCES, "usb_bulk_read: interface used without being claimed");
470c576
<     USB_ERROR(-EINVAL);
---
>     USB_ERROR_STR ( -EINVAL, "usb_bulk_read: invalid pipe reference" );
473c579,592
<     fprintf(stderr, "usb_bulk_read: endpoint=0x%02x size=%i TO=%i\n", ep, size, timeout);
---
>     fprintf(stderr, "usb_bulk_read: endpoint=0x%02x size=%i timeout=%fsec\n" , ep, size, (double)timeout/1000 );
> 
>   (*(device->interface))->GetPipeProperties ( device->interface, pipeRef, &direction, &number,
> 					     &transferType, &maxPacketSize, &interval );
> 
>   if ( transferType == kUSBInterrupt ) {
>     /* This is an interrupt pipe. We can't specify a timeout. */
>     if (usb_debug > 3)
>       fprintf(stderr, "usb_bulk_read: interrupt pipe\n" );
>     result = (*(device->interface))->ReadPipe(device->interface, pipeRef,
> 						  bytes, (UInt32 *)&ret_size);
>     if ( !result && (ret_size == 0) )
>       /* Empty interrupt read. Return. */
>       return 0;
475,479d593
<   /* now in a loop, this should fix the problems reading large amounts of data from
<      the bulk endpoint */
<   do {
<     result = (*(device->interface))->ReadPipeTO(device->interface, pipeRef,
< 					     bytes + retrieved, (UInt32 *)&ret_size, 0, timeout);
481c595
<       USB_ERROR_STR(result, "error reading from bulk endpoint %02x", ep);
---
>       USB_ERROR_STR(result, "usb_bulk_read: error reading from bulk endpoint %02x" , ep);
484,485c598,611
<     ret_size = size - retrieved;
<   } while (!result && retrieved < size);
---
>   }
>   else {
>     /* now in a loop, this should fix the problems reading large amounts of data from
>        the bulk endpoint */
>     do {
>       result = (*(device->interface))->ReadPipeTO(device->interface, pipeRef,
> 						  bytes + retrieved, (UInt32 *)&ret_size, 0, timeout);
>       if (result)
> 	USB_ERROR_STR(result, "usb_bulk_read: error reading from bulk endpoint %02x, code=%x" , ep, result);
> 
>       retrieved += ret_size;
>       ret_size = size - retrieved;
>     } while (!result && retrieved < size);
>   }
488c614
<     USB_ERROR_STR(result ? result : ret_size, "error reading from endpoint %02x", ep);
---
>     USB_ERROR_STR(result ? result : ret_size, "usb_bulk_read: error reading from endpoint %02x", ep);
496c622
<                      int value, int index, char *bytes, int size, int timeout)
---
> 		    int value, int index, char *bytes, int size, int timeout)
520c646
<     USB_ERROR_STR(result, "error sending control message");
---
>     USB_ERROR_STR(result, "usb_control_msg: error sending control message");
546c672
<    have been created if the user called usb_init() )*/
---
>      have been created if the user called usb_init() )*/
554,555c680,681
<   /* set up the matching dictionary for class IOUSBDevice and it's subclasses.
<      it will be consumed by the next call */
---
>   /* set up the matching dictionary for class IOUSBDevice and its subclasses.
>      It will be consumed by the next call */
643,644c769,770
<   /* set up the matching dictionary for class IOUSBDevice and it's subclasses.
<    it will be consumed by the next call */
---
>   /* set up the matching dictionary for class IOUSBDevice and its subclasses.
>      It will be consumed by the next call */
746c872
<     USB_ERROR_STR(-EACCES, "interface used without being claimed");
---
>     USB_ERROR_STR(-EACCES, "usb_resetep: interface used without being claimed");
751c877
<     USB_ERROR_STR(result, "error resetting pipe");
---
>     USB_ERROR_STR(result, "usb_resetep: error resetting pipe");
769c895
<     USB_ERROR_STR(-EACCES, "interface used without being claimed");
---
>     USB_ERROR_STR(-EACCES, "usb_clear_halt: interface used without being claimed");
774c900
<     USB_ERROR_STR(result, "error clearing pipe stall");
---
>     USB_ERROR_STR(result, "usb_clear_halt: error clearing pipe stall");
792c918
<     USB_ERROR_STR(-ENOENT, "no such device");
---
>     USB_ERROR_STR(-ENOENT, "usb_reset: no such device");
795,796c921
< }
< 
---
> } 

Hello!

I've put in the "patches" section of sf an improvement (from my point=20
of view :-) of the timeout mechanism for interrupt reads. (patch=20
against linux.c v1.41. I've seen that in the mean time there is a=20
1.42... sorry)

Instead of using an alarm() call (where you have to use a signal=20
handler), I propose to use a non-blocking ioctl() in combination with a=20=

sub-second timeout  (via a select() call) and real time comparison.

Ok, the process is then a little bit more "active" than before, but I=20
hate programming signal handlers...

Feedback, comments or flame are welcome!

St=E9phane

On Thu, May 15, 2003, Stephen H. Westin <we...@gr...> wrote:
> 
> I have finally gotten libusb driving a Canon digital camera under
> MacOS X. It turns out that the system sets things up for devices of
> class "Composite" that aren't recognized by the system, but devices of
> other classes, like my camera, don't have the same structures set
> up. I wrote some code to do this; I'm not sure it's really robust, but
> it works for me.
> 
> Anyway, is there any chance of incorporating this into CVS? I can't
> give you "diff" output, as I can't seem to check out anonymously from
> the SourceForge repository. Here's what I do:
> 
>   [kingslake:~/gphoto2] westin% cvs -d:pserver:ano...@cv...:/cvsroot/libusb login
>   (Logging in to ano...@cv...)
>   CVS password: 
>   cvs [login aborted]: authorization failed: server cvs.sourceforge.net rejected access
>   [kingslake:~/gphoto2] westin% 
> 
> Why does it demand a password? Is something amiss with the repository,
> or am I doing something wrong? I copied and pasted the exact command
> from the CVS Web page <http://sourceforge.net/cvs/?group_id=1674>.
> 
> Any help is appreciated.

It works for me:

belushi:~% cvs -d:pserver:ano...@cv...:/cvsroot/libusb login
Logging in to :pserver:ano...@cv...:2401/cvsroot/libusb
CVS password: 
belushi:~% 

Did you hit just enter for the password?

JE

I have finally gotten libusb driving a Canon digital camera under
MacOS X. It turns out that the system sets things up for devices of
class "Composite" that aren't recognized by the system, but devices of
other classes, like my camera, don't have the same structures set
up. I wrote some code to do this; I'm not sure it's really robust, but
it works for me.

Anyway, is there any chance of incorporating this into CVS? I can't
give you "diff" output, as I can't seem to check out anonymously from
the SourceForge repository. Here's what I do:

  [kingslake:~/gphoto2] westin% cvs -d:pserver:ano...@cv...:/cvsroot/libusb login
  (Logging in to ano...@cv...)
  CVS password: 
  cvs [login aborted]: authorization failed: server cvs.sourceforge.net rejected access
  [kingslake:~/gphoto2] westin% 

Why does it demand a password? Is something amiss with the repository,
or am I doing something wrong? I copied and pasted the exact command
from the CVS Web page <http://sourceforge.net/cvs/?group_id=1674>.

Any help is appreciated.

-Stephen H. Westin
Any information or opinions in this message are mine: they do not
represent the position of Cornell University or any of its sponsors.

On Sun, May 11, 2003, Brad Hards <bh...@bi...> wrote:
> On Sun, 11 May 2003 05:54 am, Johannes Erdfelt wrote:
> > On Sat, May 10, 2003, Brad Hards <bh...@bi...> wrote:
> > > On Fri, 9 May 2003 02:19 am, Johannes Erdfelt wrote:
> > > > usb_error_errno. It's like errno, but different.
> > >
> > > I assumed that since it wasn't exported, it shouldn't be used. In any
> > > case,
> >
> > Not exported what way?
> 
> As in, not defined in <usb.h>

Ahh, yes, it isn't in usb.h

> > > I'm still having trouble with it - the error code is 0x0. Can you prove
> > > an explanation or example?
> >
> > Looking at the code it's fundamentally flawed. We try to be helpful by
> > making the error message a bit more friendly, but the code fails to set
> > usb_error_errno.
> Looks like you originally intended to have two approaches (a string based one, 
> and a errno based one), which both got converted into strings for 
> usb_strerror().

Yes. come to think of it, I think not defining it in usb.h was by
design.

> > I think we should normalize the all of the platforms in 0.1 to something
> > similar to the error codes the Linux kernel will return, and thusly
> > libusb will return. I'm thinking Linux because I'm more familiar with it
> > and it has been used more for libusb 0.1.
> That would be good, although would it be better to normalise them to the 
> symbolic equivalents (eg -EPERM, rather than -1)?

We do this, but unfortunately it was only in some places. I've checked
in some changes to fix this for the Linux and BSD ports. Darwin will
require some documentation.

I think this is what I had originally intended but unfortunately it
wasn't completely implemented this way.

Ugh, I need to document stuff when I write it, not years after the fact
:)

JE

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, 11 May 2003 05:54 am, Johannes Erdfelt wrote:
> On Sat, May 10, 2003, Brad Hards <bh...@bi...> wrote:
> > On Fri, 9 May 2003 02:19 am, Johannes Erdfelt wrote:
> > > usb_error_errno. It's like errno, but different.
> >
> > I assumed that since it wasn't exported, it shouldn't be used. In any
> > case,
>
> Not exported what way?
As in, not defined in <usb.h>

> > I'm still having trouble with it - the error code is 0x0. Can you prove
> > an explanation or example?
>
> Looking at the code it's fundamentally flawed. We try to be helpful by
> making the error message a bit more friendly, but the code fails to set
> usb_error_errno.
Looks like you originally intended to have two approaches (a string based o=
ne,=20
and a errno based one), which both got converted into strings for=20
usb_strerror().

> I think we should normalize the all of the platforms in 0.1 to something
> similar to the error codes the Linux kernel will return, and thusly
> libusb will return. I'm thinking Linux because I'm more familiar with it
> and it has been used more for libusb 0.1.
That would be good, although would it be better to normalise them to the=20
symbolic equivalents (eg -EPERM, rather than -1)?

Brad
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+vavrW6pHgIdAuOMRArZ7AJ4/HKjXALgYgyZXKUGuFP9by+JJ2wCdEBAR
gAQIbv032E9ftQzfJ6q+FK4=3D
=3D6x+7
=2D----END PGP SIGNATURE-----

On Sat, May 10, 2003, Brad Hards <bh...@bi...> wrote:
> On Fri, 9 May 2003 02:19 am, Johannes Erdfelt wrote:
> > usb_error_errno. It's like errno, but different.
> I assumed that since it wasn't exported, it shouldn't be used. In any case, 

Not exported what way?

> I'm still having trouble with it - the error code is 0x0. Can you prove an 
> explanation or example?

Looking at the code it's fundamentally flawed. We try to be helpful by
making the error message a bit more friendly, but the code fails to set
usb_error_errno.

> > The problem with it right now is that errors from the different
> > platforms aren't normalized. So the same error on different platforms
> > might result in different error codes.
> So even if I could make it work, I'd have to condition the explanation on the 
> usb_error_errno and platform?

Possibly.

This is one of the poorly thought out and poorly implemented parts of
libusb.

I think we can fix it acceptably for 0.1 and redesign it for 1.0.

I think we should normalize the all of the platforms in 0.1 to something
similar to the error codes the Linux kernel will return, and thusly
libusb will return. I'm thinking Linux because I'm more familiar with it
and it has been used more for libusb 0.1.

Also, I should fix USB_ERROR_STR so we can set usb_error_errno to
something meaningful.

JE

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 9 May 2003 02:19 am, Johannes Erdfelt wrote:
> usb_error_errno. It's like errno, but different.
I assumed that since it wasn't exported, it shouldn't be used. In any case,=
=20
I'm still having trouble with it - the error code is 0x0. Can you prove an=
=20
explanation or example?

> The problem with it right now is that errors from the different
> platforms aren't normalized. So the same error on different platforms
> might result in different error codes.
So even if I could make it work, I'd have to condition the explanation on t=
he=20
usb_error_errno and platform?

Brad
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+vO5ZW6pHgIdAuOMRAg04AKCpT8qehq5f8/hr14z+JmvNx3+VHgCfaV7h
r3PMaW3RzTb0jgkXJt8YOwY=3D
=3DQjRC
=2D----END PGP SIGNATURE-----

On Thu, May 08, 2003, Brad Hards <bh...@bi...> wrote:
> I have some code that looks like this:
> int get_csr(struct usb_device *dev,  uint8_t *status)
> {
>     int result = 0;
>     usb_dev_handle *usb_h;
> 
>     usb_h = usb_open(dev);
>     if (0 > usb_h) {
> 	printf("Error opening usbfs file: %s\n", usb_strerror());
> 	return -1;
>     }
> 
>     result =  usb_control_msg(usb_h,
> 			      USB_TYPE_VENDOR | USB_ENDPOINT_IN,
> 			      0x09,
> 			      0x0003,
> 			      0x0000,
> 			      status,
> 			      0x0008,
> 			      1000);
> 
>     if (0 > result) {
> 	printf("Error getting cordless status from device : %s\n", usb_strerror());
>     }
> 
>     usb_close(usb_h);
> 
>     return result;
> }
> 
> Sometimes the user will see:
> Error getting cordless status from device : error sending control message: Operation not permitted
> 
> I understand that usually means that the program isn't being run with root
> access rights to the underlying device, but I'm sure my users don't. So 
> I'd like to provide a more informative error. I'm just not sure how. Normally
> I'd check errno, but that doesn't seem to help, and the return value doesn't
> seem to reflect anything reasonable.
> 
> Any tips, beyond comparing the output of the usb_strerror() with a fixed
> string and hoping that libusb hasn't been localised?

usb_error_errno. It's like errno, but different.

The problem with it right now is that errors from the different
platforms aren't normalized. So the same error on different platforms
might result in different error codes.

This is something I'd like to change in the future for 1.0.

JE

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have some code that looks like this:
int get_csr(struct usb_device *dev,  uint8_t *status)
{
    int result =3D 0;
    usb_dev_handle *usb_h;

    usb_h =3D usb_open(dev);
    if (0 > usb_h) {
	printf("Error opening usbfs file: %s\n", usb_strerror());
	return -1;
    }

    result =3D  usb_control_msg(usb_h,
			      USB_TYPE_VENDOR | USB_ENDPOINT_IN,
			      0x09,
			      0x0003,
			      0x0000,
			      status,
			      0x0008,
			      1000);

    if (0 > result) {
	printf("Error getting cordless status from device : %s\n", usb_strerror());
    }

    usb_close(usb_h);

    return result;
}

Sometimes the user will see:
Error getting cordless status from device : error sending control message: =
Operation not permitted

I understand that usually means that the program isn't being run with root
access rights to the underlying device, but I'm sure my users don't. So=20
I'd like to provide a more informative error. I'm just not sure how. Normal=
ly
I'd check errno, but that doesn't seem to help, and the return value doesn't
seem to reflect anything reasonable.

Any tips, beyond comparing the output of the usb_strerror() with a fixed
string and hoping that libusb hasn't been localised?

Brad
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE+ujGRW6pHgIdAuOMRAqdNAJ9FAM4juhDGcCMELA0gcDzAxrxsZQCcDROt
KNvIbIk0DTOj/rKSzezOFEg=3D
=3Dcdso
=2D----END PGP SIGNATURE-----

On Wed, May 07, 2003, Johann Glaser <Joh...@gm...> wrote:
> I've never seen interrupt OUT transfers. Are these possible?

They are possible. Not implemented correctly in libusb right now
however.

> BTW: Since when is libusb supporting interrupt pipes? Would be
> interesting for a project of mine too.

It's in CVS, but it's missing some code on Linux and unimplemented on
the other platforms.

JE

Hi!

The below device descriptor shows that the "serial to usb cable" comes
from Metrologic. I suspect that this isn't a real "serial to usb cable".
The barcode reader seems to recognize that the cable is not RS232 and
then generates the appropriate signals for USB.

You should contact Metrologic for information on the USB line protocol
and all specifications.

>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x02  EP 2 OUT
>         bmAttributes            3
>         Transfer Type            Interrupt
>         Synch Type               none
>         wMaxPacketSize          8
>         bInterval              10
>       Endpoint Descriptor:
>         bLength                 7
>         bDescriptorType         5
>         bEndpointAddress     0x81  EP 1 IN
>         bmAttributes            3
>         Transfer Type            Interrupt
>         Synch Type               none
>         wMaxPacketSize          8
>         bInterval              10

I've never seen interrupt OUT transfers. Are these possible?

BTW: Since when is libusb supporting interrupt pipes? Would be
interesting for a project of mine too.

Bye
  Hansi

-- 
Johann Glaser   <Joh...@gm...>
   Vienna University of Technology
       Electrical Engineering 
____ http://www.johann-glaser.at/ ____

I'm trying to interface with a Metrologic Barcode scanner. It generally
communicates with through a serial port, but we've got serial to usb cables.
We're porting some of our software to Linux from windows and the biggest
problem right now is being able to interface with this device. None of the
usb serial drivers seem to work with this device, so I'm exploring other
options.

The manual for the device says that it uses:
	9600 baud, 8 data bits, 1 stop bit, no parity
	ACK/NAK
	XON/XOFF

Is this type of communication currently possible through libusb?
What should I try?

Thanks a heap.

Device Information:
Bus 001 Device 002: ID 0c2e:0700
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.00
  bDeviceClass            0 Interface
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0c2e
  idProduct          0x0700
  bcdDevice           9c.48
  iManufacturer           1 Metro
  iProduct                2 Metrologic  Scanner
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           41
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          4
    bmAttributes         0x80
    MaxPower              300mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      1
      bInterfaceProtocol      1
      iInterface              5 EndPoint1 Interrupt
  unknown descriptor type: 09 21 00 01 00 01 22 3f 00
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
        wMaxPacketSize          8
        bInterval              10
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               none
        wMaxPacketSize          8
        bInterval              10
  Language IDs: (length=4)
     0409 English(US)

That's a bug in the current code which happens when a timeout occurs.

The code doesn't do any signal handling right now.

Are you expecting data to be delivered within 10 seconds (from looking
at the call to usb_interrupt_read)?

JE

On Tue, May 06, 2003, Derek Hansen <de...@wi...> wrote:
> I am trying to do an interrupt transfer from a device. I'm using the
> usb_interrupt_read() method.  When the method runs it prints "Alarm clock"
> to the screen and my program terminates. What could be causing this error
> and how can I remedy it?
> 
> Here is a cutting of my code:
> 
> struct usb_bus *bus;
>     struct usb_device *dev;
>     struct usb_dev_handle * handle;
> 
>     int stat;
>     int interfaceNum;
>     int altNum;
>     int endPoint;
>     int numBytes;
>     int quit;
> 
>     char buf[2048];
> 
>     usb_init();
> 
>     usb_find_busses();
>     usb_find_devices();
> 
>     for (bus=usb_get_busses(); bus; bus = bus->next) {
>      for (dev = bus->devices; dev; dev = dev->next) {
>       if ((dev->descriptor.idVendor == 0x0c2e)&&(dev->descriptor.idProduct
> == 0x0700)) {
>        printf("*****Found the metrologic scanner*****\n");
>        break;
>       }
>      }
>     }
> 
>     handle = usb_open(dev);
> 
>   stat = usb_set_configuration( handle,
> dev->config[0].bConfigurationValue );
> 
>   interfaceNum = dev->config[0].interface[0].altsetting[0].bInterfaceNumber;
>   stat = usb_claim_interface(handle, interfaceNum);
> 
>   altNum = dev->config[0].interface[0].altsetting[0].bAlternateSetting;
>   stat = usb_set_altinterface(handle, altNum);
> 
>   quit = 0;
>   while ( !quit ) {
>    printf("Reading from scanner\n");
> 
>        endPoint
> =dev->config[0].interface[0].altsetting[0].endpoint[1].bEndpointAddress;
>        numBytes
> =dev->config[0].interface[0].altsetting[0].endpoint[1].wMaxPacketSize;
> 
>        printf("%d =ep, %d = bytes\n" ,endPoint, numBytes);
> 
>        stat = usb_interrupt_read( handle, endPoint, buf, numBytes, 10000 );
> 
>        printf("Read: %s\n",buf);
> 
>        if ( stat<0 ) {
>     quit = 1;
>        }
>   }
> 
> 

I am trying to do an interrupt transfer from a device. I'm using the
usb_interrupt_read() method.  When the method runs it prints "Alarm clock"
to the screen and my program terminates. What could be causing this error
and how can I remedy it?

Here is a cutting of my code:

struct usb_bus *bus;
    struct usb_device *dev;
    struct usb_dev_handle * handle;

    int stat;
    int interfaceNum;
    int altNum;
    int endPoint;
    int numBytes;
    int quit;

    char buf[2048];

    usb_init();

    usb_find_busses();
    usb_find_devices();

    for (bus=usb_get_busses(); bus; bus = bus->next) {
     for (dev = bus->devices; dev; dev = dev->next) {
      if ((dev->descriptor.idVendor == 0x0c2e)&&(dev->descriptor.idProduct
== 0x0700)) {
       printf("*****Found the metrologic scanner*****\n");
       break;
      }
     }
    }

    handle = usb_open(dev);

  stat = usb_set_configuration( handle,
dev->config[0].bConfigurationValue );

  interfaceNum = dev->config[0].interface[0].altsetting[0].bInterfaceNumber;
  stat = usb_claim_interface(handle, interfaceNum);

  altNum = dev->config[0].interface[0].altsetting[0].bAlternateSetting;
  stat = usb_set_altinterface(handle, altNum);

  quit = 0;
  while ( !quit ) {
   printf("Reading from scanner\n");

       endPoint
=dev->config[0].interface[0].altsetting[0].endpoint[1].bEndpointAddress;
       numBytes
=dev->config[0].interface[0].altsetting[0].endpoint[1].wMaxPacketSize;

       printf("%d =ep, %d = bytes\n" ,endPoint, numBytes);

       stat = usb_interrupt_read( handle, endPoint, buf, numBytes, 10000 );

       printf("Read: %s\n",buf);

       if ( stat<0 ) {
    quit = 1;
       }
  }

On Sun, May 04, 2003, dw0811 <dw...@cn...> wrote:
> I have met a strange problem in my program.
> I have two hosts which run redhat7.3(2.4.18-3),and their usb hub was connected by a usbtousb bridge device(or PL2301),here is parts of my code:
> 
> 
>   char   recvbuf[4096];
>   char   sendbuf[4096];
> 
>         
>   int  j,sendlen;  
> 
>   strcpy(sendbuf,"STARTING");
> 
>   sendlen=4096;
> 
>   if (!strcmp(argv[1],"send"))
>   {
>    j=usb_bulk_write(udev,outendpoint,(char *)sendbuf,sendlen,5000);
>    if (j>0) 
>     printf("send %d\n",sendlen);
>    else
>       perror("Error");
>   }
> 
>   if (!strcmp(argv[1],"recv"))
>   {
>    for(;;)
>    {
>     j=usb_bulk_read(udev,inendpoint,(char *)recvbuf, sendlen,5000); 
>     if (j>0)
>     {
>        printf("recv %d\n",j);
>        printf("%s\n",recvbuf);
>        break;
>     }
>     else
>        perror("Error");  
>    }
>  }
> 
> i want run my test program on host A to send data,and another on host B to recv data,
> BUT,the data was recved by host B was unexpected,
> the data is not "STARTING",'\0' <repeats 4088 times>
> but '\0' <repeats 192 times>, "STARTING", '\0' <repeats 3896 times>
> 
> Sorry,my english is poor,i hope people here can understand me what i want to say, Thanks for your help.

I'm not too familiar with pl2301 (only the netchip 1080), but it could
be a FIFO which is causing this shifting of data. 192 bytes is a
multiple of the USB packet size, so I suspect it's just something the
pl2301 does that you may have to take into consideration.

JE

On Sun, May 04, 2003, Brad Hards <bh...@bi...> wrote:
> I've been sent a patch that changes this usage:
> 
>     usb_init();
> 
>     usb_find_busses();
>     usb_find_devices();
> 
>     for (bus = usb_busses; bus; bus = bus->next) {
> 	for (dev = bus->devices; dev; dev = dev->next) {
> 
> to this:
>     usb_init();
> 
>     usb_find_busses();
>     usb_find_devices();
>     busses = usb_get_busses();
> 
>     for (bus = busses; bus; bus = bus->next) {
> 	struct usb_device *dev;
> 	for (dev = bus->devices; dev; dev = dev->next) {
> 
> 
> I've looked at http://libusb.sourceforge.net/doc/function.usbgetbusses.html 
> and I think that the change is wrong (at least for a C application), but I'd 
> like to confirm it, if possible. Can anyone verify that the original code is 
> of the correct form? Are there any downsides to using the global variable?
> 
> If the second form is more correct, should the all the usb_find_busses() be 
> removed?

Either is fine for C programs. usb_get_busses() was added because some
other languages don't have access to variables in libraries (like Pascal
apparentely).

There is no difference in those two pieces of code functionally and will
never be for libusb 0.1 atleast.

libusb 1.0 will have a very different enumeration scheme.

JE

SSBoYXZlIG1ldCBhIHN0cmFuZ2UgcHJvYmxlbSBpbiBteSBwcm9ncmFtLg0KSSBoYXZlIHR3byBo
b3N0cyB3aGljaCBydW4gcmVkaGF0Ny4zKDIuNC4xOC0zKSxhbmQgdGhlaXIgdXNiIGh1YiB3YXMg
Y29ubmVjdGVkIGJ5IGEgdXNidG91c2IgYnJpZGdlIGRldmljZShvciBQTDIzMDEpLGhlcmUgaXMg
cGFydHMgb2YgbXkgY29kZToNCg0KDQogIGNoYXIgICByZWN2YnVmWzQwOTZdOw0KICBjaGFyICAg
c2VuZGJ1Zls0MDk2XTsNCg0KICAgICAgICANCiAgaW50ICBqLHNlbmRsZW47ICANCg0KICBzdHJj
cHkoc2VuZGJ1ZiwiU1RBUlRJTkciKTsNCg0KICBzZW5kbGVuPTQwOTY7DQoNCiAgaWYgKCFzdHJj
bXAoYXJndlsxXSwic2VuZCIpKQ0KICB7DQogICBqPXVzYl9idWxrX3dyaXRlKHVkZXYsb3V0ZW5k
cG9pbnQsKGNoYXIgKilzZW5kYnVmLHNlbmRsZW4sNTAwMCk7DQogICBpZiAoaj4wKSANCiAgICBw
cmludGYoInNlbmQgJWRcbiIsc2VuZGxlbik7DQogICBlbHNlDQogICAgICBwZXJyb3IoIkVycm9y
Iik7DQogIH0NCg0KICBpZiAoIXN0cmNtcChhcmd2WzFdLCJyZWN2IikpDQogIHsNCiAgIGZvcig7
OykNCiAgIHsNCiAgICBqPXVzYl9idWxrX3JlYWQodWRldixpbmVuZHBvaW50LChjaGFyICopcmVj
dmJ1Ziwgc2VuZGxlbiw1MDAwKTsgDQogICAgaWYgKGo+MCkNCiAgICB7DQogICAgICAgcHJpbnRm
KCJyZWN2ICVkXG4iLGopOw0KICAgICAgIHByaW50ZigiJXNcbiIscmVjdmJ1Zik7DQogICAgICAg
YnJlYWs7DQogICAgfQ0KICAgIGVsc2UNCiAgICAgICBwZXJyb3IoIkVycm9yIik7ICANCiAgIH0N
CiB9DQoNCmkgd2FudCBydW4gbXkgdGVzdCBwcm9ncmFtIG9uIGhvc3QgQSB0byBzZW5kIGRhdGEs
YW5kIGFub3RoZXIgb24gaG9zdCBCIHRvIHJlY3YgZGF0YSwNCkJVVCx0aGUgZGF0YSB3YXMgcmVj
dmVkIGJ5IGhvc3QgQiB3YXMgdW5leHBlY3RlZCwNCnRoZSBkYXRhIGlzIG5vdCAiU1RBUlRJTkci
LCdcMCcgPHJlcGVhdHMgNDA4OCB0aW1lcz4NCmJ1dCAnXDAnIDxyZXBlYXRzIDE5MiB0aW1lcz4s
ICJTVEFSVElORyIsICdcMCcgPHJlcGVhdHMgMzg5NiB0aW1lcz4NCg0KU29ycnksbXkgZW5nbGlz
aCBpcyBwb29yLGkgaG9wZSBwZW9wbGUgaGVyZSBjYW4gdW5kZXJzdGFuZCBtZSB3aGF0IGkgd2Fu
dCB0byBzYXksIFRoYW5rcyBmb3IgeW91ciBoZWxwLg==