libusb-devel Mailing List for libusb

On Thu, Jul 29, 2004, Daniel Miller (IMI) <da...@im...> wrote:
> I have a machine here which has 12 USB slots on it (it's a testing device).
> My application uses libusb to communicate with the devices, and I've been
> struggling for some time now with a memory leak, which I believe I've now
> traced down to libusb.  If I comment out the call to the libusb
> data-collection function, the memory leak goes away (I'm monitoring the leak
> by watching my program segment size with pmap).  If I add the following code
> and loop on it, I see my memory usage increase by about 200KB/minute:
> 
>    usb_init(); //  set up internal usb_path[] variable
>    usb_find_busses();
>    usb_find_devices();
> 
>    usb_found = 0 ;
>    for (bus = usb_busses; bus; bus = bus->next) {
>       ibus = atoi( bus->dirname );
>       for (dev = bus->devices; dev; dev = dev->next) {
>          continue;
> 
>       }  //  for each USB dev on bus
>    }  //  for each USB bus
> 
> I'm using linux kernel 2.6.7, libusb version 0.1.8.
> 
> Is there some cleanup function that I'm supposed to use when I'm done with a
> set of devices??  I based this code on the testlibusb.c application, but
> maybe it doesn't bother with otherwise-necessary cleanup... is this
> possible?  If not, is this a bug in libusb??

Since the only function that is being called in your loop is a libc
function, I don't see how you can claim this is a libusb problem.

What am I missing?

JE

An additional piece of info that I omitted from my previous message is that
we are removing and re-inserting the devices before each scan with libusb.
This simulates the actual testing environment that the machine will
experience.  So although the the same device is in each slot on every scan,
the USB IDs have probably changed.  My suspicion is that when libusb builds
its list, it either isn't really deleting the removed devices properly, or
it isn't freeing the memory that it allocated.  I haven't been able to
clearly track the program flow, though...

    Dan Miller

P.S.
I'm sorry I didn't make this a reply to my previous message; I couldn't find
a "reply to post" option on the sourceforge site.

I have a machine here which has 12 USB slots on it (it's a testing device).
My application uses libusb to communicate with the devices, and I've been
struggling for some time now with a memory leak, which I believe I've now
traced down to libusb.  If I comment out the call to the libusb
data-collection function, the memory leak goes away (I'm monitoring the leak
by watching my program segment size with pmap).  If I add the following code
and loop on it, I see my memory usage increase by about 200KB/minute:

   usb_init(); //  set up internal usb_path[] variable
   usb_find_busses();
   usb_find_devices();

   usb_found = 0 ;
   for (bus = usb_busses; bus; bus = bus->next) {
      ibus = atoi( bus->dirname );
      for (dev = bus->devices; dev; dev = dev->next) {
         continue;

      }  //  for each USB dev on bus
   }  //  for each USB bus

I'm using linux kernel 2.6.7, libusb version 0.1.8.

Is there some cleanup function that I'm supposed to use when I'm done with a
set of devices??  I based this code on the testlibusb.c application, but
maybe it doesn't bother with otherwise-necessary cleanup... is this
possible?  If not, is this a bug in libusb??

    Dan Miller

Hi all,
looks like it's not a libusb problem.

I took the hexpad example from cypress (simple usb-usermode access).
First of all i had to claim the interface cos i got 
"Jul 22 13:33:36 C1VE kernel: usb 1-1: usbfs: process 8584 (bulk_out) did not 
claim interface 0 before use"
in syslog.
The first thing is, that the fitting ioctrl- call returns a -1, but errno says 
"Success" -thats why i used that stupid ==.

I also added some strerror and printf calls.
http://www.erazor-zone.de/ez/projects/linux/ezusb/bulk_out.c
As you can see it only consits of ioctl calls, but i got that "Invalid 
argument" again.

C1VE hexpad # getdevpath -v 0547 -p 2131 | ./bulk_out -c00
bulk xfer error Invalid argument

Well, i can't image where that error i coming from... 
I'm sure i only used the kernel headers and since they are from 2.6.7 and i'm 
using a 2.6.7 kernel everything should be ok.

I'm quite confused :-(

cheers -Alex

Hi JE,

> Can you try the CVS version? It handles bulk transfers differently and
> might work, but it would effectively be a workaround since there should
> be no reason the old method fails.
Well, i compiled the last CVS version and recompiled usb-robot.
Now i'm getting something like:
C1VE ezusb # usb-robot-slave 
usb-robot-slave: starting usb-robot version 0.2.0
  (c) 2000, 2001 John Fremlin
  Licensed under the GNU Public License version 2, see file COPYING.
  You didn't pay me for this program. You have no rights.
doing bus scan for:
        any idVendor
        any idProduct
found bus 001
scanning bus 001
found device 004 on bus 001 (idVendor 0x547 idProduct 0x2131)
opening device 004 on bus 001
OK: id=0
Type help and press return for a list of commands
usb-robot> interface 0
OK: id=1
usb-robot> encoding hex
Output format changed to hex
OK: id=2
usb-robot> decoding hex
Input format changed to hex
OK: id=3
usb-robot> transfer type=bulk ep=2 dir=out size=1
Enter data in format FF FB 00 FC
00
doing bulk transfer id 4 to ep 0x2, size 1, timeout 10000 frames
status: problem doing write
usb error: error submitting URB: No such file or directory
ERROR: id=4
usb-robot> 


:-(

cheers -Alex

On Jul 21, 2004, at 21:12, Paul Klissner wrote:

> Sun Microsystems is planning on porting javax.usb (JSR 80 - 
> http://www.jcp.org)
> to leverage libusb entirely, if possible.  It will need to see a more 
> full featured
> libusb API in advance of that.  We are currently in the process of 
> determining
> exactly what the needs are for libusb 1.0, from that standpoint.
>
> That might be another avenue for you to consider.

Hi Paul:

	I've been watching the Javax.usb project for some time now (I used to 
be in fairly constant communication with the core developers back when 
I used to work for IBM).  One intelligent design decision I made early 
on in the jSyncManager Project was to allow for plug-in classes to be 
developed to provide the access to the various connectivity APIs the 
project might eventually need to use.

	A javax.usb plug-in has been on our to-do list for quite some time, 
but with a Linux-only reference implementation it hasn't been a 
priority.

	I've long believed that javax.usb will eventually be our salvation -- 
but currently its lack of availability on non-Linux platforms is 
holding us back.

	Writing JNI bindings for libusb, and coding a plug-in for it directly 
is probably our best intermediary step, as we'd like to have USB 
support on Mac OS X, BSD, Windows, and Solaris  next week, as opposed 
to months from now.  As multiple plug-ins can be available at once, we 
can always provide one for javax.usb to replace a libusb JNI bindings 
plug-in once it's readily available on other platforms (we only have so 
many developers and so much time).  We actually have president for this 
-- the jSyncManager was conceptualized back in 1997, before the 
(public) existence of the Java Communications API, which necessitated 
my writing the jSerial API.  Once JavaComm was available, we made the 
JavaComm plug-in the recommended/default serial access API.

	It's good to know that javax.usb may eventually rely on libusb for its 
access to USB (makes sense IMO).  I'll keep watching the javax.usb 
mailing list for more information.  Until then, I'm going to continue 
writing the JNI for accessing libusb from Java (as the lack of a decent 
cross-platform, Java-accessible USB API is holding up several 
corporations using our project for their data synchronization needs).

	Thanks for the info!

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

=-=-=-=-=-=-=-=-=-=
 From the Mac OS X Desktop of Brad BARCLAY
E-Mail:  bba...@js...     Web:  http://www.jsyncmanager.org

Sun Microsystems is planning on porting javax.usb (JSR 80 - 
http://www.jcp.org)
to leverage libusb entirely, if possible.  It will need to see a more 
full featured
libusb API in advance of that.  We are currently in the process of 
determining
exactly what the needs are for libusb 1.0, from that standpoint.

That might be another avenue for you to consider.

Paul Klissner
Staff Engineer
Sun Ray I/O Developer
Sun Microsystems, Inc.


Brad BARCLAY wrote:

> Good-day Everyone:
> 
>     I'm the project administrator and lead developer for the 
> jSyncManager Project, a 6 year-old project that provides the necessary 
> protocols, data abstraction objects, and applications for synchronizing 
> PalmOS-based handhelds with any Java enabled system.  The project is 
> Open Source, and is available through SourceForge at 
> http://sf.jsyncmanager.org.
> 
>     The core project provides support for the necessary protocols to 
> synchronize via serial ports, USB, InfraRed, Bluetooth, TCP/IP and USB, 
> however as the project is pure Java, we need to rely on third-party APIs 
> to talk to the actual hardware layer (in every case but TCP/IP).  The 
> Java Communications API is readily available on every major platform, 
> but USB has been another situation.
> 
>     Our current USB support is through jUSB 
> (http://jusb.sourceforge.net), and while this works extremely well, it's 
> only viable for use on Linux.  We'd prefer not to limit what OS platform 
> our users choose, and as such I'm looking for solutions to cover other 
> OS's, like Mac OS X, Windows, OS/2, etc.
> 
>     libusb has some excellent platform coverage, so I'm currently 
> considering undertaking a side-project to write JNI-bindings for 
> accessing libusb's functionality.  This implementation would expose 
> every libusb data structure and function to Java applications (and yes, 
> before you ask, I have a lot of experience in this area).
> 
>     Before I get started, some questions:
> 
> 0) Has anybody already started such a project?  (Preliminary searching 
> on Google didn't turn up anything, but I ask just in case),
> 
> 1) Would the libusb project maintainer(s) like to host this code in 
> their source repository? (it would, of course, be licensed as Open 
> Source under the LGPL), and
> 
> 2) Are there any developers here interested in helping with such a venture?
> 
>     Thanks for your time!
> 
> Brad BARCLAY
> Lead Developer & Project Administrator,
> The jSyncManager Project.
> 
> =-=-=-=-=-=-=-=-=-=
>  From the Mac OS X Desktop of Brad BARCLAY
> E-Mail:  bba...@js...     Web:  http://www.jsyncmanager.org
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

Good-day Everyone:

	I'm the project administrator and lead developer for the jSyncManager 
Project, a 6 year-old project that provides the necessary protocols, 
data abstraction objects, and applications for synchronizing 
PalmOS-based handhelds with any Java enabled system.  The project is 
Open Source, and is available through SourceForge at 
http://sf.jsyncmanager.org.

	The core project provides support for the necessary protocols to 
synchronize via serial ports, USB, InfraRed, Bluetooth, TCP/IP and USB, 
however as the project is pure Java, we need to rely on third-party 
APIs to talk to the actual hardware layer (in every case but TCP/IP).  
The Java Communications API is readily available on every major 
platform, but USB has been another situation.

	Our current USB support is through jUSB (http://jusb.sourceforge.net), 
and while this works extremely well, it's only viable for use on Linux. 
  We'd prefer not to limit what OS platform our users choose, and as 
such I'm looking for solutions to cover other OS's, like Mac OS X, 
Windows, OS/2, etc.

	libusb has some excellent platform coverage, so I'm currently 
considering undertaking a side-project to write JNI-bindings for 
accessing libusb's functionality.  This implementation would expose 
every libusb data structure and function to Java applications (and yes, 
before you ask, I have a lot of experience in this area).

	Before I get started, some questions:

0) Has anybody already started such a project?  (Preliminary searching 
on Google didn't turn up anything, but I ask just in case),

1) Would the libusb project maintainer(s) like to host this code in 
their source repository? (it would, of course, be licensed as Open 
Source under the LGPL), and

2) Are there any developers here interested in helping with such a 
venture?

	Thanks for your time!

Brad BARCLAY
Lead Developer & Project Administrator,
The jSyncManager Project.

=-=-=-=-=-=-=-=-=-=
 From the Mac OS X Desktop of Brad BARCLAY
E-Mail:  bba...@js...     Web:  http://www.jsyncmanager.org

On Mon, Jul 19, 2004 at 12:00:46PM -0700, Johannes Erdfelt wrote:
> Can you try the CVS version? It handles bulk transfers differently and
> might work, but it would effectively be a workaround since there should
> be no reason the old method fails.

FWIW I use libusb 0.1.8 in a gentoo system without any problems. 2.6.7
kernel. Only interrupt transfer so far, though.


//Peter

> libusb doesn't compile against the linux-headers. It keeps a private
> copy so it doesn't have to worry about these kinds of incompatibilities.
>
> I don't know what the problem can be then if you're using the same
> application with the same kernel then.
>
> Can you try the CVS version? It handles bulk transfers differently and
> might work, but it would effectively be a workaround since there should
> be no reason the old method fails.
well, i could try it.

so far, thanks a lot!

cheers alex

On Mon, Jul 19, 2004, Alexander 'E-Razor' Krause <ad...@er...> wrote:
> > What kernel are you using with SuSE and what kernel are you using with
> > gentoo?
> I used different ones, on SuSE a vanilla 2.4.26... i tried the same on gentoo 
> too -without success
> 
> I suppose glibc and libusb compile against the linux-headers 
> (/lib/include/linux)... well, i tested different headers too.... downgrading 
> them... upgrading... and so on... recompiled glibc and libusb everytime (i'm 
> actually using 2.6.5 headers with 2.6.7 kernel)

libusb doesn't compile against the linux-headers. It keeps a private
copy so it doesn't have to worry about these kinds of incompatibilities.

I don't know what the problem can be then if you're using the same
application with the same kernel then.

Can you try the CVS version? It handles bulk transfers differently and
might work, but it would effectively be a workaround since there should
be no reason the old method fails.

JE

On Mon, Jul 19, 2004, Alexander 'E-Razor' Krause <ad...@er...> wrote:
> On Monday 19 July 2004 20:33, Johannes Erdfelt wrote:
> > Can you post the contents of /prob/bus/usb/devices ?
> oh, sorry... its quite late :-P

That's alright. Maybe you should get some sleep, because you forgot to
answer my last question :)

> >What version of libusb is installed on SuSE and what version is
> >installed on gentoo?
> on both:
> C1VE ezusb # emerge -s libusb
> Searching...   
> [ Results for search key : libusb ]
> [ Applications found : 1 ]
>  
> *  dev-libs/libusb
>       Latest version available: 0.1.8
>       Latest version installed: 0.1.8
>       Size of downloaded files: 313 kB
>       Homepage:    http://libusb.sourceforge.net/
>       Description: Userspace access to USB devices
>       License:     LGPL-2
> 
> the usb-robot versions is equal too, but as i said it's not a libusb problem, 
> it's something with usb-usermode access in general.
> 
> I said i wrote an own program (without libusb) calling something like that:
>   tmp.ep = ep | USB_DIR_OUT;
>   tmp.len = len;
>   tmp.timeout = timeout;
>   tmp.data = data;
>
>   ret = ioctl(dev->fd, USBDEVFS_BULK, &tmp);
> 
> (i'm sure libusb uses ioctl too)

Yes, it does.

> the response is the same:
> C1VE bulktest # ./bulktest
> bulk out (64 bytes): 
> 20 c9 03 40 a8 39 13 40 04 00 00 00 03 00 00 00 a8 f0 ff bf 90 a9 00 40 04 00 
> 00 00 e4 3c 13 40 40 ff 0c 40 00 00 03 40 45 ff 0c 40 71 66 04 40 03 00 00 00 
> e4 3c 13 40 04 00 00 00 03 00 00 00
> USBDEVFS_BULKOUT (ep=0x2 len=64) error Invalid argument
> bulk out failed, err=-1
> bulk in failed, err=-1

It could be a difference in the kernel, but you didn't answer that
question from my previous email, so it's hard to say if it is.

JE

> What kernel are you using with SuSE and what kernel are you using with
> gentoo?
I used different ones, on SuSE a vanilla 2.4.26... i tried the same on gentoo 
too -without success

I suppose glibc and libusb compile against the linux-headers 
(/lib/include/linux)... well, i tested different headers too.... downgrading 
them... upgrading... and so on... recompiled glibc and libusb everytime (i'm 
actually using 2.6.5 headers with 2.6.7 kernel)

On Monday 19 July 2004 20:33, Johannes Erdfelt wrote:
> Can you post the contents of /prob/bus/usb/devices ?
oh, sorry... its quite late :-P

C1VE ezusb # 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.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.7-gentoo-r7 uhci_hcd
S:  Product=Intel Corp. 82371AB/EB/MB PIIX4 USB
S:  SerialNumber=0000:00:07.2
C:* #Ifs= 1 Cfg#= 1 Atr=c0 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=   2 Ivl=255ms

T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  5 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=ff(vend.) Sub=ff Prot=ff MxPS=64 #Cfgs=  1
P:  Vendor=0547 ProdID=2131 Rev= 0.04
C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I:  If#= 0 Alt= 1 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=10ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=88(I) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=08(O) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=89(I) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=09(O) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=8a(I) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=0a(O) Atr=01(Isoc) MxPS=  16 Ivl=1ms
I:  If#= 0 Alt= 2 #EPs=13 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=81(I) Atr=03(Int.) MxPS=  64 Ivl=10ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=84(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=06(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=88(I) Atr=01(Isoc) MxPS= 256 Ivl=1ms
E:  Ad=08(O) Atr=01(Isoc) MxPS= 256 Ivl=1ms
E:  Ad=89(I) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=09(O) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=8a(I) Atr=01(Isoc) MxPS=  16 Ivl=1ms
E:  Ad=0a(O) Atr=01(Isoc) MxPS=  16 Ivl=1ms

T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  2 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=054c ProdID=0032 Rev= 1.31
S:  Manufacturer=Sony
S:  Product=USB Memory Stick Slot
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=08(stor.) Sub=04 Prot=00 Driver=usb-storage
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=83(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

>What version of libusb is installed on SuSE and what version is
>installed on gentoo?
on both:
C1VE ezusb # emerge -s libusb
Searching...   
[ Results for search key : libusb ]
[ Applications found : 1 ]
 
*  dev-libs/libusb
      Latest version available: 0.1.8
      Latest version installed: 0.1.8
      Size of downloaded files: 313 kB
      Homepage:    http://libusb.sourceforge.net/
      Description: Userspace access to USB devices
      License:     LGPL-2

the usb-robot versions is equal too, but as i said it's not a libusb problem, 
it's something with usb-usermode access in general.

I said i wrote an own program (without libusb) calling something like that:
  tmp.ep = ep | USB_DIR_OUT;                                                    
  tmp.len = len;                                                                
  tmp.timeout = timeout;                                                        
  tmp.data = data;                                                              
                                                                                
  ret = ioctl(dev->fd, USBDEVFS_BULK, &tmp);                                    

(i'm sure libusb uses ioctl too)
the response is the same:
C1VE bulktest # ./bulktest
bulk out (64 bytes): 
20 c9 03 40 a8 39 13 40 04 00 00 00 03 00 00 00 a8 f0 ff bf 90 a9 00 40 04 00 
00 00 e4 3c 13 40 40 ff 0c 40 00 00 03 40 45 ff 0c 40 71 66 04 40 03 00 00 00 
e4 3c 13 40 04 00 00 00 03 00 00 00
USBDEVFS_BULKOUT (ep=0x2 len=64) error Invalid argument
bulk out failed, err=-1
bulk in failed, err=-1

On Mon, Jul 19, 2004, Alexander 'E-Razor' Krause <ad...@er...> wrote:
> Hi Johannes!
> 
> > Can you post the contents of /proc/bus/usb/devices ?
> C1VE erazor # lsusb
> Bus 001 Device 004: ID 0547:2131 Anchor Chips, Inc. AN2131 EZUSB 
> Microcontroller
> Bus 001 Device 002: ID 054c:0032 Sony Corp. MemoryStick MSC-U01 Reader
> Bus 001 Device 001: ID 0000:0000 
> 
> C1VE erazor # usbtree 
> /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
>     |__ Port 1: Dev 4, If 0, Class=vend., Driver=none, 12M
>     |__ Port 2: Dev 2, If 0, Class=stor., Driver=usb-storage, 12M
> 
> C1VE erazor # ls -R /proc/bus/usb/
> /proc/bus/usb/:
> 001  devices
> 
> /proc/bus/usb/001:
> 001  002  004
> 
> well, i think thats enough, tell me if youre needing some more details about 
> the possible configurations and so on.
> (btw, ep2 IN/OUT is valid with config 1, max size is 64)

Actually, that wasn't enough. You gave me everything but what I actually
asked for.

Can you post the contents of /prob/bus/usb/devices ?

> > Can you also post the code for the libusb call that fails?
> not exactly cos i'm using usb-robot-slave, but may i could post the line where 
> t calls the bulk transfer:
> @control.c:488
>     case transfer_bulk:
>       message( "doing bulk transfer id %d %s ep 0x%x, size %d, timeout %d 
> frames", 
>                (int)context->id,
>                direction_to_string[dir],
>                (int)ep,
>                (int)size,
>                (int)timeout );
>
>       if ( ep == -1 )
>         {
>           fprintf( context->out, "USERERROR: no value for ep given\n" );
>           return -2;
>         }
>       switch(dir)
>         {
>         case dir_in:
>           if ( (read = usb_bulk_read(context->device, ep, data, size,
> timeout)) !=
>             {
>               if ( read > 0 )
>                 usb_error( "problem doing read; only %d read from %d",
> (int)read, (
>               else
>                 usb_error( "problem doing read" );
>
>               return_value = -1;
>               break;
>             }

It looks like some of the code is missing. It looks fine at first
glance.

> --
> here is, what i wrote on usb-robot-slave:
> C1VE ezusb # usb-robot-slave
> usb-robot-slave: starting usb-robot version 0.2.0
>   (c) 2000, 2001 John Fremlin
>   Licensed under the GNU Public License version 2, see file COPYING.
>   You didn't pay me for this program. You have no rights.
> doing bus scan for:
>         any idVendor
>         any idProduct
> found bus 001
> scanning bus 001
> found device 004 on bus 001 (idVendor 0x547 idProduct 0x2131)
> opening device 004 on bus 001
> OK: id=0
> Type help and press return for a list of commands
> usb-robot> interface 0
> OK: id=1
> usb-robot> config 1
> OK: id=2
> usb-robot> encoding hex
> Output format changed to hex
> OK: id=3
> usb-robot> decoding hex
> Input format changed to hex
> OK: id=4
> usb-robot> transfer type=bulk dir=OUT ep=2 size=1
> Enter data in format FF FB 00 FC
> 00
> doing bulk transfer id 6 to ep 0x2, size 1, timeout 10000 frames
> status: problem doing write
> usb error: error writing to bulk endpoint 2: Invalid argument
> ERROR: id=5
> usb-robot> quit
> quiting on request
> usb-robot-slave: exiting happily
> 
> C1VE ezusb # tail /var/log/messages
> hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
> hub 1-0:1.0: debounce: port 1: delay 100ms stable 4 status 0x101
> usb 1-1: new full speed USB device using address 4
> usb 1-1: new device strings: Mfr=0, Product=0, SerialNumber=0
> usb 1-1: hotplug
> usb 1-1: adding 1-1:1.0 (config #1, interface 0)
> usb 1-1:1.0: hotplug
> usb 1-1: usbfs: interface 0 claimed while 'usb-robot-slave' sets config #1
> 
> well and what happened when using a control-transfer is written in the last 
> mail :-(
> 
> I'm quite sure something is wrong with my system, as i wrote everything works 
> with SuSE but not with an actual gentoo.

What version of libusb is installed on SuSE and what version is
installed on gentoo?

What kernel are you using with SuSE and what kernel are you using with
gentoo?

JE

Hi Johannes!

> Can you post the contents of /proc/bus/usb/devices ?
C1VE erazor # lsusb
Bus 001 Device 004: ID 0547:2131 Anchor Chips, Inc. AN2131 EZUSB 
Microcontroller
Bus 001 Device 002: ID 054c:0032 Sony Corp. MemoryStick MSC-U01 Reader
Bus 001 Device 001: ID 0000:0000 

C1VE erazor # usbtree 
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
    |__ Port 1: Dev 4, If 0, Class=vend., Driver=none, 12M
    |__ Port 2: Dev 2, If 0, Class=stor., Driver=usb-storage, 12M

C1VE erazor # ls -R /proc/bus/usb/
/proc/bus/usb/:
001  devices

/proc/bus/usb/001:
001  002  004

well, i think thats enough, tell me if youre needing some more details about 
the possible configurations and so on.
(btw, ep2 IN/OUT is valid with config 1, max size is 64)

> Can you also post the code for the libusb call that fails?
not exactly cos i'm using usb-robot-slave, but may i could post the line where 
t calls the bulk transfer:
@control.c:488
    case transfer_bulk:                                                            
      message( "doing bulk transfer id %d %s ep 0x%x, size %d, timeout %d 
frames", 
               (int)context->id,                                                   
               direction_to_string[dir],                                           
               (int)ep,                                                            
               (int)size,                                                          
               (int)timeout );                                                     
                                                                                   
      if ( ep == -1 )                                                              
        {                                                                          
          fprintf( context->out, "USERERROR: no value for ep given\n" );           
          return -2;                                                               
        }                                                                          
      switch(dir)                                                                  
        {                                                                          
        case dir_in:                                                               
          if ( (read = usb_bulk_read(context->device, ep, data, size, 
timeout)) != 
            {                                                                      
              if ( read > 0 )                                                      
                usb_error( "problem doing read; only %d read from %d", 
(int)read, (
              else                                                                 
                usb_error( "problem doing read" );                                 
                                                                                   
              return_value = -1;                                                   
              break;                                                               
            }                    
--
here is, what i wrote on usb-robot-slave:
C1VE ezusb # usb-robot-slave
usb-robot-slave: starting usb-robot version 0.2.0
  (c) 2000, 2001 John Fremlin
  Licensed under the GNU Public License version 2, see file COPYING.
  You didn't pay me for this program. You have no rights.
doing bus scan for:
        any idVendor
        any idProduct
found bus 001
scanning bus 001
found device 004 on bus 001 (idVendor 0x547 idProduct 0x2131)
opening device 004 on bus 001
OK: id=0
Type help and press return for a list of commands
usb-robot> interface 0
OK: id=1
usb-robot> config 1
OK: id=2
usb-robot> encoding hex
Output format changed to hex
OK: id=3
usb-robot> decoding hex
Input format changed to hex
OK: id=4
usb-robot> transfer type=bulk dir=OUT ep=2 size=1
Enter data in format FF FB 00 FC
00
doing bulk transfer id 6 to ep 0x2, size 1, timeout 10000 frames
status: problem doing write
usb error: error writing to bulk endpoint 2: Invalid argument
ERROR: id=5
usb-robot> quit
quiting on request
usb-robot-slave: exiting happily

C1VE ezusb # tail /var/log/messages
hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 1: delay 100ms stable 4 status 0x101
usb 1-1: new full speed USB device using address 4
usb 1-1: new device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: hotplug
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
usb 1-1:1.0: hotplug
usb 1-1: usbfs: interface 0 claimed while 'usb-robot-slave' sets config #1

well and what happened when using a control-transfer is written in the last 
mail :-(

I'm quite sure something is wrong with my system, as i wrote everything works 
with SuSE but not with an actual gentoo.

so far
--
cheers -Alex

On Sat, Jul 17, 2004, Alexander 'E-Razor' Krause <ad...@er...> wrote:
> Hi all, i'm forwarding this message cos i got no response from the gentoo 
> forum yet.
> (emerge compiles the package $1, $1="-C" means clean or uninstall)
> 
> --
> Hi, first of all, thankx for ANY help... i'm really confused since some weeks 
> cos of this problem. 
>  
>  Well, i played a bit with an ezusb (in more detail the an2131) with a self- 
> made board. 
>  I wrote some programs for endpoint zero calls using libusb -works quite fine! 
>  So, now i started with some more normal endpoint calls, for example bulk 
> -OUT' via ep2 and so on -i tried firstly the hexpad example from cypress 
> without any trouble. 
>  
>  But after a while i'm getting very curios error messages, for example in 
> usb-robot-slave: 
>  
>  doing control message id 3 from device, size 2, timeout 10000 frames, 
> c0:a0:7f9a:0 
>  status: problem doing control msg 
>  usb error: No error 
>  ERROR: id=3 
>  
>  i wrote some sentences before this problem appears -see this page: 
>  http://projects.erazor-zone.de/ezusb/ 
>  
>  or every time using a normal bulk transfer ends with "invalid argument". 
>  I used this commands in usb-robot: 
>  usb-robot-slave 
>  encoding hex 
>  decoding hex 
>  transfer type=bulk dir=out ep=2 size=1 
>  01 
>  => ended with invalid argument  
>  
>  I'm absolutely clueless (btw: the device seems ok cos everything works fine 
> under windows and for example SuSE Linux). 
>  Well, syslog isn't very helpfull too even with verbose set in kernel. 
>  
>  After all i tried different things: 
>  -another gentoo system (x86 instead of ~x86) 
>  -downgrading linux-headers to something like 2.4.20 and after that emerge 
> usb-robot libusb 
>  -emerge hotplug hotplug-base 
>  -playing a bit with fxload (firmware download works -well it's the same as 
> using ep0 calls) 
>  -different kernels (2.4.24, 2.4.26-gentoo,2.6.5, 2.6.7-gentoo-r8 ) 
>  -tried direct usbfs ioctl (without libusb) 
>  -used different endpoints + firmware 
>  -prelink -afmr (because i upgraded glibc) 
>  -emerge -C linux-headers; emerge linux-headers glibc libusb usb-robot 
>  -emerge -C linux-headers; emerge linux26-headers glibc libusb usb-robot 
>  
>  And yes i used to be root. 
>  
>  Finally i'm really pissed-off!  
>  
>  As i said, thanks for ANY help! 

Can you post the contents of /proc/bus/usb/devices ?

Can you also post the code for the libusb call that fails?

JE

Hi all, i'm forwarding this message cos i got no response from the gentoo 
forum yet.
(emerge compiles the package $1, $1="-C" means clean or uninstall)

--
Hi, first of all, thankx for ANY help... i'm really confused since some weeks 
cos of this problem. 
 
 Well, i played a bit with an ezusb (in more detail the an2131) with a self- 
made board. 
 I wrote some programs for endpoint zero calls using libusb -works quite fine! 
 So, now i started with some more normal endpoint calls, for example bulk 
-OUT' via ep2 and so on -i tried firstly the hexpad example from cypress 
without any trouble. 
 
 But after a while i'm getting very curios error messages, for example in 
usb-robot-slave: 
 
 doing control message id 3 from device, size 2, timeout 10000 frames, 
c0:a0:7f9a:0 
 status: problem doing control msg 
 usb error: No error 
 ERROR: id=3 
 
 i wrote some sentences before this problem appears -see this page: 
 http://projects.erazor-zone.de/ezusb/ 
 
 or every time using a normal bulk transfer ends with "invalid argument". 
 I used this commands in usb-robot: 
 usb-robot-slave 
 encoding hex 
 decoding hex 
 transfer type=bulk dir=out ep=2 size=1 
 01 
 => ended with invalid argument  
 
 I'm absolutely clueless (btw: the device seems ok cos everything works fine 
under windows and for example SuSE Linux). 
 Well, syslog isn't very helpfull too even with verbose set in kernel. 
 
 After all i tried different things: 
 -another gentoo system (x86 instead of ~x86) 
 -downgrading linux-headers to something like 2.4.20 and after that emerge 
usb-robot libusb 
 -emerge hotplug hotplug-base 
 -playing a bit with fxload (firmware download works -well it's the same as 
using ep0 calls) 
 -different kernels (2.4.24, 2.4.26-gentoo,2.6.5, 2.6.7-gentoo-r8 ) 
 -tried direct usbfs ioctl (without libusb) 
 -used different endpoints + firmware 
 -prelink -afmr (because i upgraded glibc) 
 -emerge -C linux-headers; emerge linux-headers glibc libusb usb-robot 
 -emerge -C linux-headers; emerge linux26-headers glibc libusb usb-robot 
 
 And yes i used to be root. 
 
 Finally i'm really pissed-off!  
 
 As i said, thanks for ANY help! 

Peter Stuge wrote:
> On Thu, Jul 15, 2004 at 07:54:43AM +0200, Bertrik Sikken wrote:
> 
>>>what are the usb devices for which 'libusb'API would
>>>be suitable ?
>>
>>I think basically all devices which do not have a pre-
>>specified class, like mentioned earlier.
>>
>>USB scanners are mostly supported by libusb (in Linux 2.6
>>the 'scanner' kernel driver was dropped), see
>>http://sane-project.org/
>>
>>The libnetmd effort to support NetMD Minidisc players is also
>>using libusb, see http://sourceforge.net/projects/libnetmd/
> 
> 
> Right. libusb could also be used to implement support for device
> classes that don't fit into a corresponding kernel subsystem already.
> 
> One such example is the CCID class, Chip/Smart Card Interface Devices.
> Another is the Test & Measurement Class.

And it is even possible to use libusb and user-mode code to implement
most USB mass storage support as well, just providing a very simple
kernel loopback driver to provide block and character interfaces for
legacy apps that need to see them and the appropriate entry points for
the kernel filesystem code (which itself could be implemented in user
space if you wanted to do that).

mike

-- 
----------------------------------------------------------------------------
   Michael Bender                       E-Mail: Mic...@su...
   Sun Microsystems, Inc.                  Tel: 831-401-9510
   14 Network Circle                       Tel: x.31807
   Menlo Park, Ca. 94025
   Mailstop: UMPK14-260                    MD: VPN/IMAP

         We are judged not by our abilities, but by our choices.

----------------------------------------------------------------------------

On Thu, Jul 15, 2004 at 07:54:43AM +0200, Bertrik Sikken wrote:
> >what are the usb devices for which 'libusb'API would
> >be suitable ?
> 
> I think basically all devices which do not have a pre-
> specified class, like mentioned earlier.
> 
> USB scanners are mostly supported by libusb (in Linux 2.6
> the 'scanner' kernel driver was dropped), see
> http://sane-project.org/
> 
> The libnetmd effort to support NetMD Minidisc players is also
> using libusb, see http://sourceforge.net/projects/libnetmd/

Right. libusb could also be used to implement support for device
classes that don't fit into a corresponding kernel subsystem already.

One such example is the CCID class, Chip/Smart Card Interface Devices.
Another is the Test & Measurement Class.


//Peter

Vikram Kumar wrote:
>>libusb is really handy for making userspace
>>applications talk to devices with vendor-specific
>>protocols without a lot of effort by the programmer.
>>Class drivers (such as Audio, Communications class,
>>Imaging, Storage, HID ...) will probably be much
>>better off inside the kernel, however. They fit
>>there much better conceptually too.
> 
> 
> Thanks for enlightening me ! Now I would like 2
> emulate the driver in the kernel space !
> 
> what are the usb devices for which 'libusb'API would
> be suitable ?

I think basically all devices which do not have a pre-
specified class, like mentioned earlier.

USB scanners are mostly supported by libusb (in Linux 2.6
the 'scanner' kernel driver was dropped), see
http://sane-project.org/

The libnetmd effort to support NetMD Minidisc players is also
using libusb, see http://sourceforge.net/projects/libnetmd/

Regards,
Bertrik

>libusb is really handy for making userspace
>applications talk to devices with vendor-specific
>protocols without a lot of effort by the programmer.
>Class drivers (such as Audio, Communications class,
>Imaging, Storage, HID ...) will probably be much
>better off inside the kernel, however. They fit
>there much better conceptually too.

Thanks for enlightening me ! Now I would like 2
emulate the driver in the kernel space !

what are the usb devices for which 'libusb'API would
be suitable ?

Regards,
Vikram.




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

On Wed, Jul 14, 2004 at 04:20:35AM -0700, Vikram Kumar wrote:
> >Do you REALLY want to do this?    In order to
> >communicate with your USB Storage Class device you
> >would  have to reimplement the usb-storage class
> >driver which is already in  the kernel, 
> 
> >//Peter
> 
> Thanks Peter for replying
> Im aware that USB-Storage is already installed & this
> pen drive does work perfectly as SCSI device!

Ok.


> I want to learn Libusb because I feel this interface
> takes the pain out of developing drivers for USB
> devices on Linux. 

Well, it allows you to make them in userspace, which is a good thing
in many ways, but there are also drawbacks.


> Currently are there no built-in fuctions to accomplish
> the work USB-storage.o in 'libusb' ?

Correct. And there shouldn't be either.


> Whats the role of USBFS in the current context ?

It's primarily a handy method of exporting information about devices
attached to the USB from the kernel to userspace. To some extent it
also allows userspace applications to control the kernel USB stack.


> Can't we use that in reading or writing to mass
> storage devices ?

Not really. At least not by itself. Read on.


> Any solutions to the above probs ?

The purpose of libusb is to abstract different OS kernel USB stacks
into an easier-to-use programmer's library that can be used to send
and receive unformatted data to/from endpoints on devices.

usbfs assists in this e.g. by allowing libusb to search the bus for
a device with a vendor id and product id that matches those supplied
by the programmer. On Linux. Other OS:s don't have usbfs and there
libusb uses other means to learn what devices are connected where.

There may be some point in moving usb-storage from kernelspace to
userspace, since less kernel code is always better, but my guess is
that doing so is not really practical even with the 2.6 kernel
because usb-storage uses the SCSI subsystem in the kernel. This is
a topic for the linux-kernel or linux-usb-devel mailing list, though.

libusb is really handy for making userspace applications talk to
devices with vendor-specific protocols without a lot of effort by
the programmer. Class drivers (such as Audio, Communications class,
Imaging, Storage, HID ...) will probably be much better off inside
the kernel, however. They fit there much better conceptually too.

Hope this helps,


//Peter

>Do you REALLY want to do this?    In order to
>communicate with your USB Storage Class device you
>would  have to reimplement the usb-storage class
>driver which is already in  the kernel, 

>//Peter

Thanks Peter for replying
Im aware that USB-Storage is already installed & this
pen drive does work perfectly as SCSI device!

I want to learn Libusb because I feel this interface
takes the pain out of developing drivers for USB
devices on Linux. 

Currently are there no built-in fuctions to accomplish
the work USB-storage.o in 'libusb' ?

Whats the role of USBFS in the current context ?

Can't we use that in reading or writing to mass
storage devices ?

Any solutions to the above probs ?




		
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail

On Tue, Jul 13, 2004 at 07:26:35PM -0700, Vikram Kumar wrote:
> Hello Experts,
> 
> LIBUSB is a boon for all developers who want to make
> their usb devices work on linux quickly!!!
> 
>                 Trying to write a custom driver for my
> USB Pen Drive using LIBUSB on Fedora I .
> 
> My whole aim is to claim the interface then read &
> write to the pen drive .

Do you REALLY want to do this?

In order to communicate with your USB Storage Class device you would
have to reimplement the usb-storage class driver which is already in
the kernel, and working quite well.

Add SCSI support and USB storage support and watch a SCSI disk show
up in your system when you plug the device. Then mount it somewhere.


//Peter