libusb-devel

Re: [Libusb-devel] user permission

[Johannes E. <joh...@er...>]

On Sat, Jul 14, 2001, Shaun Jackman <sja...@ho...> wrote:
> How do you give a user r/w permission to a USB device accessed through 
> libusb? Can a specific device be specified, or do you have to give them 
> generic access to all USB devices?

libusb doesn't do that. That's up to the system.

With Linux, you can modify the permissions and/or ownership of the
device in /proc/bus/usb by hand (using chmod and chown respectively). Or
you can change the default permissions and/or ownership by using options
when loading the usbcore module.

Under the BSD's, you would modify the permissions and/or ownership of
the device in /dev

JE

[Libusb-devel] user permission

[Shaun J. <sja...@ho...>]

How do you give a user r/w permission to a USB device accessed through 
libusb? Can a specific device be specified, or do you have to give them 
generic access to all USB devices?

Thanks,
Shaun

[Libusb-devel] njb gettr bugfix

[Shaun J. <sja...@ho...>]

gettr works with a small fix (patch at then end)

in base.c njb->xfersize wasn't getting set

the #include <linux/usb.h> is redundant. #include <usb.h> should be enough. 
(it was causing compiler warnings)

Is there some way to get the file size from the njb? so that the -s switch to 
gettr need not be specified.

Cheers,
Shaun


Index: base.c
===================================================================
RCS file: /var/cvs/libnjb/src/base.c,v
retrieving revision 1.1.1.3
diff -c -u -r1.1.1.3 base.c
cvs diff: conflicting specifications of output style
--- base.c      11 Jul 2001 07:27:00 -0000      1.1.1.3
+++ base.c      13 Jul 2001 09:06:55 -0000
@@ -9,7 +9,6 @@
 #include <errno.h>
 #ifdef HAVE_LIBUSB
 #include <usb.h>
-#include <linux/usb.h>
 #else
 #include <dev/usb/usb.h>
 #endif
@@ -359,12 +358,12 @@
  */
                }
        }
+#endif
 
        njb->xfersize= DEF_XFER_BLOCK_SIZE;
        njb->reset_get_track_tag= 1;
        njb->reset_get_playlist= 1;
        njb->reset_get_datafile_tag= 1;
-#endif
        return 0;
 }

[Libusb-devel] njb off_t size porting problem

[Shaun J. <sja...@ho...>]

From the looks of the code it assumes off_t is 64 bit. On my Linux system 
it's a mere 32 bit which creates problems with get_disk_usage (6GB hard disk 
space > max 32 bit 4GB). I've attached a patch that changes any off_t 
referring to the NJB *only* (eg not a local file, which I left as off_t) to 
u_int64_t.

Shaun


Index: libnjb.h
===================================================================
RCS file: /var/cvs/libnjb/src/libnjb.h,v
retrieving revision 1.1.1.3
diff -c -u -r1.1.1.3 libnjb.h
--- libnjb.h	11 Jul 2001 07:27:00 -0000	1.1.1.3
+++ libnjb.h	13 Jul 2001 08:32:00 -0000
@@ -200,7 +200,7 @@
 songid_t *NJB_Get_Track_Tag (njb_t *njb);
 void NJB_Reset_Get_Playlist (njb_t *njb);
 playlist_t *NJB_Get_Playlist (njb_t *njb);
-int NJB_Get_Disk_Usage (njb_t *njb, off_t *btotal, off_t *bfree);
+int NJB_Get_Disk_Usage (njb_t *njb, u_int64_t *btotal, u_int64_t *bfree);
 char *NJB_Get_Owner_String (njb_t *njb);
 int NJB_Set_Owner_String (njb_t *njb, char *name);
 void NJB_Reset_Get_Datafile_Tag (njb_t *njb);
Index: procedure.c
===================================================================
RCS file: /var/cvs/libnjb/src/procedure.c,v
retrieving revision 1.1.1.2
diff -c -u -r1.1.1.2 procedure.c
--- procedure.c	7 Jul 2001 20:44:39 -0000	1.1.1.2
+++ procedure.c	13 Jul 2001 08:36:06 -0000
@@ -212,7 +212,7 @@
 	return njb_get_playlist(njb, &plh);
 }
 
-int NJB_Get_Disk_Usage (njb_t *njb, off_t *btotal, off_t *bfree)
+int NJB_Get_Disk_Usage (njb_t *njb, u_int64_t *btotal, u_int64_t *bfree)
 {
 	__dsub= "NJB_Get_Disk_Usage";
 
@@ -485,7 +485,8 @@
 	XferCallback *callback, u_int32_t *trackid)
 {
 	__dsub= "NJB_Send_Track";
-	off_t btotal, bfree, size;
+	u_int64_t btotal, bfree;
+	off_t size;
 	songid_t song;
 	songid_frame_t *frame;
 	unsigned char *ptag;
@@ -590,7 +591,8 @@
 	XferCallback *callback, u_int32_t *fileid)
 {
 	__dsub= "NJB_Send_File";
-	off_t btotal, bfree, size;
+	u_int64_t btotal, bfree;
+	off_t size;
 	datafile_t df;
 	int status;
 
Index: protocol.c
===================================================================
RCS file: /var/cvs/libnjb/src/protocol.c,v
retrieving revision 1.1.1.3
diff -c -u -r1.1.1.3 protocol.c
--- protocol.c	11 Jul 2001 07:27:00 -0000	1.1.1.3
+++ protocol.c	13 Jul 2001 08:37:31 -0000
@@ -296,7 +296,7 @@
 	return pl;
 }
 
-int njb_get_disk_usage (njb_t *njb, off_t *total, off_t *free)
+int njb_get_disk_usage (njb_t *njb, u_int64_t *total, u_int64_t *free)
 {
 	__dsub= "njb_get_disk_usage";
 	unsigned char data[17];
@@ -318,13 +318,13 @@
 	memcpy(&lsdw, &data[5], 4);
 	msdw= utoh32(msdw);
 	lsdw= utoh32(lsdw);
-	*total= (off_t) make64(msdw, lsdw);
+	*total= make64(msdw, lsdw);
 
 	memcpy(&msdw, &data[9], 4);
 	memcpy(&lsdw, &data[13], 4);
 	msdw= utoh32(msdw);
 	lsdw= utoh32(lsdw);
-	*free= (off_t) make64(msdw, lsdw);
+	*free= make64(msdw, lsdw);
 
 	return 0;
 }
Index: protocol.h
===================================================================
RCS file: /var/cvs/libnjb/src/protocol.h,v
retrieving revision 1.1.1.2
diff -c -u -r1.1.1.2 protocol.h
--- protocol.h	7 Jul 2001 20:44:39 -0000	1.1.1.2
+++ protocol.h	13 Jul 2001 08:33:16 -0000
@@ -73,7 +73,7 @@
 int njb_verify_last_command (njb_t *njb);
 int njb_capture (njb_t *njb, int which);
 int njb_reset_get_songlist (njb_t *njb);
-int njb_get_disk_usage (njb_t *njb, off_t *total, off_t *free);
+int njb_get_disk_usage (njb_t *njb, u_int64_t *total, u_int64_t *free);
 int njb_get_owner_string (njb_t *njb, owner_string name);
 int njb_set_owner_string (njb_t *njb, owner_string name);
 int njb_request_file (njb_t *njb, u_int32_t fileid);

Re: [Libusb-devel] libnjb 0.5a released

[Enigma <en...@cu...>]

> Greetings,
> 
> I have cleaned up the sources to libnjb and completed the Linux port (thanks
> to everyone for their contributions).  The new sources are posted on my site
> at http://www.aracnet.com/~seagull/NJB/
>
> My Linux system has reproduced the "every other connection times out"
> issue, but I have not been able to track it down.  I don't think it's a
> short read issue as it is under *BSD, since Linux defaults to allowing
> short reads (you have to explicitely set a transfer flag to disabled
> short read support).  But I'm still stumbling in the dark.

I have also been looking at this, i too am pretty much stumbling round in
the dark, i have tried different kernels alos, from 2.4.0 to 2.4.6, i'm
going to guess from this that it's not a kernel issue (i might be wrong,
but i'll look at libusb first i think), i've looked at the libusb source
for bulk reads before and it looked ok to my untrained eye, maybe now i
will spot something, i'll let you know if i fond anything
 
> I also sent a note to the owner of the Nomad Jukebox project at Source
> Forge, but have not received a reply.
> 
> 
> Cheers,
> -+JLS
> 
> -- 
>                                 \                carpe cavy!
> seagull @ aracnet.com            \
> http://www.aracnet.com/~seagull   \        (seize the guinea pig!)
> 
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libusb-devel
> 


________________________________________________________

PGP key is here -> http://www.computerbooth.com/pgp.html

* If debugging is the process of removing bugs, then programming must be the
process of putting them in. 

[Libusb-devel] libnjb 0.5a released

[Seagull <se...@sh...>]

Greetings,

I have cleaned up the sources to libnjb and completed the Linux port (thanks
to everyone for their contributions).  The new sources are posted on my site
at http://www.aracnet.com/~seagull/NJB/

My Linux system has reproduced the "every other connection times out"
issue, but I have not been able to track it down.  I don't think it's a
short read issue as it is under *BSD, since Linux defaults to allowing
short reads (you have to explicitely set a transfer flag to disabled
short read support).  But I'm still stumbling in the dark.

I also sent a note to the owner of the Nomad Jukebox project at Source
Forge, but have not received a reply.


Cheers,
-+JLS

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

Re: [Libusb-devel] libnjb & linux

[Enigma <en...@cu...>]

sounds like a plan :)

On Sat, 7 Jul 2001 se...@ar... wrote:

> Date: Sat, 7 Jul 2001 19:31:24 -0700 (PDT)
> From: se...@ar...
> To: Shaun Jackman <sja...@ho...>
> Cc: lib...@li...
> Subject: Re: [Libusb-devel] libnjb & linux
> 
> > Good work Seagull! Your port to Linux (libusb) looks great! Much cleaner than 
> > my own.
> 
> Thanks.  I will be cleaning it up some more over the next few days.
> 
> > Just thought you'd be interested in seeing some results from your work.
> > Now the bugfixes... one to protocol.c and one to play.c
> 
> I am, and thanks for the bug fixes.
> 
> I am wondering now if we shouldn't start up a project at sourceforge...or
> at least commandeer the one that is already there (which currently has only
> one member and no activity).
> 
> 
> Cheers,
> -+JLS
> 
> -- 
>                                 \                carpe cavy!
> seagull @ aracnet.com            \
> http://www.aracnet.com/~seagull   \        (seize the guinea pig!)
> 
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libusb-devel
> 


________________________________________________________

PGP key is here -> http://www.computerbooth.com/pgp.html

* If debugging is the process of removing bugs, then programming must be the
process of putting them in. 

Re: [Libusb-devel] libnjb & linux

[<se...@ar...>]

> Good work Seagull! Your port to Linux (libusb) looks great! Much cleaner than 
> my own.

Thanks.  I will be cleaning it up some more over the next few days.

> Just thought you'd be interested in seeing some results from your work.
> Now the bugfixes... one to protocol.c and one to play.c

I am, and thanks for the bug fixes.

I am wondering now if we shouldn't start up a project at sourceforge...or
at least commandeer the one that is already there (which currently has only
one member and no activity).


Cheers,
-+JLS

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

Re: [Libusb-devel] libnjb & linux

[Shaun J. <sja...@ho...>]

Good work Seagull! Your port to Linux (libusb) looks great! Much cleaner than 
my own. The every-other-handshake failure persists though. It doesn't matter 
how much time is left between runs. It's likely related to short reads.
I've been running through the samples:

handshake - WORKS
play - WORKS
tracks - WORKS (w/ bugfix)
playlists - WORKS
pl - intermittent
gettr - error
	bad track size 0
deltr - untested
sendtr - untested

It's a little hard to explain what happens when I run pl, but it sometimes 
kinda works, sometimes times out. The symptoms look kind of similar to the 
every-other-handshake problem. I haven't had much of a chance to troubleshoot 
yet. School is getting in the way of my education.

Just thought you'd be interested in seeing some results from your work.
Now the bugfixes... one to protocol.c and one to play.c

Cheers, Shaun

Index: src/protocol.c
===================================================================
RCS file: /var/cvs/libnjb/src/protocol.c,v
retrieving revision 1.1.1.2
diff -c -c -r1.1.1.2 protocol.c
*** src/protocol.c	7 Jul 2001 20:44:39 -0000	1.1.1.2
--- src/protocol.c	7 Jul 2001 21:09:50 -0000
***************
*** 256,261 ****
--- 256,262 ----
  	if ( song == NULL ) return NULL;
  
  	song->trid= tagh->trackid;
+ 	return song;
  }
  
  int njb_get_playlist_header (njb_t *njb, njbplhdr_t *plh, int cmd)
***************

Index: sample/play.c
===================================================================
RCS file: /var/cvs/libnjb/sample/play.c,v
retrieving revision 1.1.1.1
diff -c -c -r1.1.1.1 play.c
*** sample/play.c	23 Jun 2001 09:40:40 -0000	1.1.1.1
--- sample/play.c	7 Jul 2001 20:47:27 -0000
***************
*** 53,75 ****
  
  	printf("---> Hit ^C to exit <---\n");
  
! 	i= 1;
! 	printf("Track ID %10.10s: 00:00:00\b\b\b\b\b\b\b", argv[i]);
! 	fflush(stdout);
! 	while ( repeat ) {
! 		NJB_Elapsed_Time(njb, &sec, &change);
  		if ( change ) {
  			i++;
  			if ( i == argc ) {
  				repeat= 0;
  			} else {
! 				printf("\rTrack ID %10.10s: 00:00:00\b\b\b\b\b\b\b",
  					argv[i]);
  				fflush(stdout);
  			}
! 		}
  		hhmmss(sec, &hh, &mm, &ss);
! 		printf("%02u:%02u:%02u\b\b\b\b\b\b\b", mm, ss);
  		fflush(stdout);
  
  		sleep(1);
--- 53,76 ----
  
  	printf("---> Hit ^C to exit <---\n");
  
! 	change = 1;
! 	i = 0;
! 	while( repeat) {
  		if ( change ) {
  			i++;
  			if ( i == argc ) {
  				repeat= 0;
  			} else {
! 				printf("\rTrack ID %10.10s: 00:00:00\b\b\b\b\b\b\b\b",
  					argv[i]);
  				fflush(stdout);
  			}
! 			change = 0;
! 		} else
! 			NJB_Elapsed_Time(njb, &sec, &change);
! 
  		hhmmss(sec, &hh, &mm, &ss);
! 		printf("%02u:%02u:%02u\b\b\b\b\b\b\b\b", hh, mm, ss);
  		fflush(stdout);
  
  		sleep(1);

On Saturday 07 July 2001 10:47, Enigma wrote:
> There are a couple of things that need changing to port this to linux,
>
> they are all 1 line changes and are listed below, the start of each line
> is what to change it to, then my comment so i know what i changed, then
> what it used to be
>
> protocol.c:459:         return 0; //Enigma hack NULL;
> protocol.c:683:         return 0; //Enigma hack NULL;
> protocol.c:704:         return 0; //Enigma hack NULL;
> protocol.c:710:         return 0; //Enigma hack NULL;
> protocol.c:713:         return 0; //Enigma hack NULL;
> protocol.c:830:         return 0; //Enigma hack NULL;
> protocol.c:920:         return 0; //Enigma hack NULL;
> usb_byteorder.c:3:#include <endian.h> //Enigma hack #include
> <machine/endian.h>
>
> this is because linux sees NULL as a pointer, and complains when returning
> a point from a function that is prototyped to return an int :)
>
> the bottom line is just a different path to the file, after this it all
> compliles fine, the only problem is the bulk timeouts now, i will have a
> look at this
>
> thanks again to seagull
>
> cheers
>
> ________________________________________________________
>
> PGP key is here -> http://www.computerbooth.com/pgp.html
>
> * If debugging is the process of removing bugs, then programming must be
> the process of putting them in.
>
>
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libusb-devel

[Libusb-devel] libnjb & linux

[Enigma <en...@cu...>]

There are a couple of things that need changing to port this to linux, 

they are all 1 line changes and are listed below, the start of each line
is what to change it to, then my comment so i know what i changed, then
what it used to be

protocol.c:459:         return 0; //Enigma hack NULL;
protocol.c:683:         return 0; //Enigma hack NULL;
protocol.c:704:         return 0; //Enigma hack NULL;
protocol.c:710:         return 0; //Enigma hack NULL;
protocol.c:713:         return 0; //Enigma hack NULL;
protocol.c:830:         return 0; //Enigma hack NULL;
protocol.c:920:         return 0; //Enigma hack NULL;
usb_byteorder.c:3:#include <endian.h> //Enigma hack #include 
<machine/endian.h>

this is because linux sees NULL as a pointer, and complains when returning
a point from a function that is prototyped to return an int :)

the bottom line is just a different path to the file, after this it all
compliles fine, the only problem is the bulk timeouts now, i will have a
look at this

thanks again to seagull

cheers

________________________________________________________

PGP key is here -> http://www.computerbooth.com/pgp.html

* If debugging is the process of removing bugs, then programming must be the
process of putting them in. 

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[Seagull <se...@ar...>]

> in that case if you send me what you've got i will see if i can get it to
> go under linux if you want?

See v0.4a which I have just posted:

   http://www.aracnet.com/~seagull/NJB/protocol/

Note that this was a quick-and-dirty port.  A lot of the baggage in
protocol.c will go away in v0.5.


Cheers,
-+JLS

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

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[Enigma <en...@cu...>]

> > On Fri, 6 Jul 2001 se...@ar... wrote:
> >
> > i suspect others are much further through this than i am, all i  can
> > do is ping and get lib counter atm (although it returns 0x00000000, which
> > looks wrong)
> 
> I have all of the NJB code working under libusb on FreeBSD.  It should be
> a really short step to getting it working under Linux at this point.
> 
> Theoretically, anyway.  :)
>

in that case if you send me what you've got i will see if i can get it to
go under linux if you want?
 
> > when you say released to you mean using the njb release or just usb_close
> > ?
> 
> I mean njb_release.

not got that far yet :)

>
> > as i haven't completed the handshake i havn't done the njb capture stuff
> > yet, this is just the trying to get the handshake working,
> 
> Depends on the functions you are calling.  NJB_Handshake() does call
> njb_capture()
>

i was rewritting it as i thought that would be easier to me (and help me
understand it better) than just tring to port it, but if you have
something that works with libusb then it would be much easier to port
(seing as it should just work :P)

>
> > although it could well be as the first read
> > is 58 bytes not 64, usb stuff sin't my strong point, only been looking at
> > it a week :)
> 
> Okay...sounds like libusb under Linux also does not handle short reads
> properly.  Almost all of the bulk pipe communications on the NJB are
> short (less than the max packet value for the endpoint, which is 64
> bytes).  I ran into this with FreeBSD, and have a cheap hack that fixes
> the problem in that OS.  I'm not familiar with Linux's USB stack yet,
> so it may take some reading before I have a solution.

i could have a look at this

> > before i forget, thanks for the protocol information on your site :)
> 
> You are welcome.  By the way, there's a bug in songid.c that I just found
> last night: in songid_unpack():
> 
>    memcpy(&nframes, dp, 4);
> 
> should be:
> 
>    memcpy(&nframes, dp, 2);
> 

________________________________________________________

PGP key is here -> http://www.computerbooth.com/pgp.html

* If debugging is the process of removing bugs, then programming must be the
process of putting them in. 

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[Seagull <se...@ar...>]

> On Fri, 6 Jul 2001 se...@ar... wrote:
>
> i suspect others are much further through this than i am, all i  can
> do is ping and get lib counter atm (although it returns 0x00000000, which
> looks wrong)

I have all of the NJB code working under libusb on FreeBSD.  It should be
a really short step to getting it working under Linux at this point.

Theoretically, anyway.  :)

> when you say released to you mean using the njb release or just usb_close
> ?

I mean njb_release.

> as i haven't completed the handshake i havn't done the njb capture stuff
> yet, this is just the trying to get the handshake working,

Depends on the functions you are calling.  NJB_Handshake() does call
njb_capture()

> although it could well be as the first read
> is 58 bytes not 64, usb stuff sin't my strong point, only been looking at
> it a week :)

Okay...sounds like libusb under Linux also does not handle short reads
properly.  Almost all of the bulk pipe communications on the NJB are
short (less than the max packet value for the endpoint, which is 64
bytes).  I ran into this with FreeBSD, and have a cheap hack that fixes
the problem in that OS.  I'm not familiar with Linux's USB stack yet,
so it may take some reading before I have a solution.

> before i forget, thanks for the protocol information on your site :)

You are welcome.  By the way, there's a bug in songid.c that I just found
last night: in songid_unpack():

   memcpy(&nframes, dp, 4);

should be:

   memcpy(&nframes, dp, 2);


Cheers,
-+JLS

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

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[Enigma <en...@cu...>]

On Fri, 6 Jul 2001 se...@ar... wrote:

> I'm also working on the libusb port under FreeBSD.  At some point, we should
> get our code together...
>

i suspect others are much further through this than i am, all i  can
do is ping and get lib counter atm (although it returns 0x00000000, which
looks wrong)
 
> 
> What kind of a lag time do you have between attempts?  Several seconds?
> Several minutes?  A few seconds?  One or two seconds?  The reason for asking
> is that, after the NJB is released, there is a period of several seconds
> during which it does not respond to USB requests.
> 

when you say released to you mean using the njb release or just usb_close
?

as i haven't completed the handshake i havn't done the njb capture stuff
yet, this is just the trying to get the handshake working, i stuck a 1
minute sleep in there, then ran it all again and it still fails
alternatly, the first one always works though, so i don't think it's the
same problem you were seeing, although it could well be as the first read
is 58 bytes not 64, usb stuff sin't my strong point, only been looking at
it a week :)

before i forget, thanks for the protocol information on your site :)

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


________________________________________________________

PGP key is here -> http://www.computerbooth.com/pgp.html

* If debugging is the process of removing bugs, then programming must be the
process of putting them in. 

[Libusb-devel] Bulk pipes, short transfers and FreeBSD

[Seagull <se...@ar...>]

Greetings,

I have finally figured out why I am getting timeouts when I call
usb_bulk_read() under FreeBSD 4.3 when speaking with the Creative NJB.

The problem is short read support, which is not provided in libusb, and
the way the FreeBSD 4.3 handles short reads on either the ugen device,
in the uhci device, or within the USB stack (it's not clear exactly which
is the culprit).  What's not clear is how to solve the problem.

The problem is that the ioctl(2) for USB_SET_SHORT_XFER must be called
on the bulk endpoint before _any_ communications are sent on the bulk or
control pipes (that is, before any ioctl() calls for USB_DO_REQUEST,
which is what usb_control_msg() invokes, or bulk reads/writes).  If the
USB_SET_SHORT_XFER ioctl() is not made prior to these data transfers,
then read requests on the bulk pipe for less than the max packet size
(a short read) will fail on a timeout.

Where this really becomes a problem is in the way libusb opens the bulk
pipes.  Essentially, they are not opened until a bulk data transfer is
requested.  This makes it difficult to ensure that the bulk pipe is
configured to allow short reads prior to any control messages.

What I have done as a workaround is this:

   1. Added the ioctl() call for USB_SET_SHORT_XFER in ensure_ep_open()

   2. Immediately after opening the device, I make a call to
      usb_bulk_read, requesting 0 bytes of data.  This forces the
      USB_SET_SHORT_XFER ioctl() without actually invoking a read()
      on the pipe

If I do this, all my bulk communications function properly.  If I don't,
my very first bulk read call fails on a timeout.

I don't know where the fault lies.  Certainly, libusb has got to provide
support for short reads (both on the bulk and control pipes).  But
whether this odd behavior is do to ugen.c (which I doubt), uhci.c or
somewhere else, I don't know.


Cheers,
-+JLS

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

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[Brad H. <bh...@bi...>]

Shaun Jackman wrote:
<snip>
> As for your ping problem, I'm seeing the exact same symtptom. The handshake
> fails every other time. I haven't started troubleshooting this yet.
The only thing that occurs to me is that the data toggle isn't getting
set/reset correctly. Maybe a code problem, maybe a device problem.

Brad

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[<se...@ar...>]

> I've also been doing a libusb port of libnjb. It's coming along nicely (I can 
> handshake, ping, download tracklists, control playback) but I don't have a 
> lot of time right now as I'm in school. Perhaps we could avoid some 
> duplication of effort and colaborate on this front?

I'm also working on the libusb port under FreeBSD.  At some point, we should
get our code together...

> As for your ping problem, I'm seeing the exact same symtptom. The handshake 
> fails every other time. I haven't started troubleshooting this yet.

What kind of a lag time do you have between attempts?  Several seconds?
Several minutes?  A few seconds?  One or two seconds?  The reason for asking
is that, after the NJB is released, there is a period of several seconds
during which it does not respond to USB requests.


Cheers,
-+JLS

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

Re: [Libusb-devel] libusb Creative jukebox and bulk timeouts

[Shaun J. <sja...@ho...>]

Hi,
I've also been doing a libusb port of libnjb. It's coming along nicely (I can 
handshake, ping, download tracklists, control playback) but I don't have a 
lot of time right now as I'm in school. Perhaps we could avoid some 
duplication of effort and colaborate on this front?

As for your ping problem, I'm seeing the exact same symtptom. The handshake 
fails every other time. I haven't started troubleshooting this yet.

Cheers,
Shaun


On Friday 06 July 2001 05:56, Enigma wrote:
> Hi
>   I have been looking at doing a port/hack/mix/break of seaguls njb stuff
> for linux, i've got as far as doing a 'ping' during the handshake, this
> sends a command and the receives 58 bytes of the bulk interface, this
> seems to work, on alternate attemps, the first time it will work, the next
> attemp it will fail with this error message
>
> Jul  2 19:42:00 hubble kernel: usb_control/bulk_msg: timeout
> Jul  2 19:42:00 hubble kernel: usbdevfs: USBDEVFS_BULK failed dev 4 ep
> 0x82 len 58 ret -110
>
> the next attempt will work, then fail etc etc,
>
> my lib currently discovers the njb using usb_find_busses and
> usb_find_devices, this always works
>
> then it does an open using usb_open usb_claim_interface and
> usb_set_altinterface, this too works fine
>
> this i do the ping, this sends a control message using usb_control_msg, i
> have checked the return value and this works too, then it does the
> usb_bulk_read, which is the bit that fails on alternate attempts
>
> i then do a usb_close on the njb and quit, each run goes through every
> step, the close always happens regardless of the failed read, this was
> designed to be a simple test for me to see if i could get things working,
> but it isn't at the moment, can anyone spot any obvious errors or give me
> hints as to why i get the bulk timeout (timeout is 3000, so it shouldn't
> be too short)
>
> Thanks in advance
>
>
> ________________________________________________________
>
> PGP key is here -> http://www.computerbooth.com/pgp.html
>
> * If debugging is the process of removing bugs, then programming must be
> the process of putting them in.
>
>
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libusb-devel

[Libusb-devel] libusb Creative jukebox and bulk timeouts

[Enigma <en...@cu...>]

Hi
  I have been looking at doing a port/hack/mix/break of seaguls njb stuff
for linux, i've got as far as doing a 'ping' during the handshake, this
sends a command and the receives 58 bytes of the bulk interface, this
seems to work, on alternate attemps, the first time it will work, the next
attemp it will fail with this error message

Jul  2 19:42:00 hubble kernel: usb_control/bulk_msg: timeout
Jul  2 19:42:00 hubble kernel: usbdevfs: USBDEVFS_BULK failed dev 4 ep
0x82 len 58 ret -110

the next attempt will work, then fail etc etc, 

my lib currently discovers the njb using usb_find_busses and
usb_find_devices, this always works

then it does an open using usb_open usb_claim_interface and
usb_set_altinterface, this too works fine

this i do the ping, this sends a control message using usb_control_msg, i
have checked the return value and this works too, then it does the
usb_bulk_read, which is the bit that fails on alternate attempts

i then do a usb_close on the njb and quit, each run goes through every
step, the close always happens regardless of the failed read, this was
designed to be a simple test for me to see if i could get things working,
but it isn't at the moment, can anyone spot any obvious errors or give me
hints as to why i get the bulk timeout (timeout is 3000, so it shouldn't
be too short)

Thanks in advance


________________________________________________________

PGP key is here -> http://www.computerbooth.com/pgp.html

* If debugging is the process of removing bugs, then programming must be the
process of putting them in. 

[Libusb-devel] Dealing with functional descriptors

[Brad H. <bh...@bi...>]

G'day all,

For devices that add special functional descriptors (e.g the DFU class and the
communication class), it would be nice to have a standard way of accessing
them. The underlying linux code uses (for example), the following data
structure to access the "extra" information.
/* Interface descriptor */
struct usb_interface_descriptor {
	__u8  bLength		__attribute__ ((packed));
	__u8  bDescriptorType	__attribute__ ((packed));
	__u8  bInterfaceNumber	__attribute__ ((packed));
	__u8  bAlternateSetting	__attribute__ ((packed));
	__u8  bNumEndpoints	__attribute__ ((packed));
	__u8  bInterfaceClass	__attribute__ ((packed));
	__u8  bInterfaceSubClass __attribute__ ((packed));
	__u8  bInterfaceProtocol __attribute__ ((packed));
	__u8  iInterface	__attribute__ ((packed));

  	struct usb_endpoint_descriptor *endpoint;

   	unsigned char *extra;   /* Extra descriptors */
	int extralen;
};

which translates into the following:
/* Interface descriptor */
struct usb_interface_descriptor {
	u_int8_t  bLength;
	u_int8_t  bDescriptorType;
	u_int8_t  bInterfaceNumber;
	u_int8_t  bAlternateSetting;
	u_int8_t  bNumEndpoints;
	u_int8_t  bInterfaceClass;
	u_int8_t  bInterfaceSubClass;
	u_int8_t  bInterfaceProtocol;
	u_int8_t  iInterface;
} __attribute__ ((packed));

So there is no "easy" way to get at the .extra and .extralen elements.
Now the format and length is pretty much impossible to know in advance (except
for the first two fields in the descriptor, of course), so I am not sure how
this would best be handled. Any thoughts? How does this issue look for BSD?

Brad

Re: [Libusb-devel] libusb and libnjb

[<se...@ar...>]

> Anyway, what I can do is point you at the library I have been building 
> for the Intel Pocket Concert, which uses libusb.  The general
> architecture of my Pocket Concert API is very, very similar to 
> my libnjb architecture, and will show you how I went about modifying
> my NJB approach to work with libusb.

Almost forgot: the source file you are probably most interested in is
"base.c".  You'll notice how much sorter it is in the Intel Pocket 
Concert package, thanks to the fact that libusb provides functions
for what had to be done "by hand" in NetBSD and FreeBSD before libusb 
was available on those platforms.


Cheers,
-+JLS

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

Re: [Libusb-devel] libusb and libnjb

[<se...@ar...>]

> I've started porting libnjb (Nomad Jukebox) to libusb so as to support Linux; 
> it was originally written for BSD USB. Is there any documentation on the 
> libusb API, or some sample code that might help get me started?

There is not much documentation on libusb API the last I looked at it
(v0.1.3b).  However, I have played with libusb a bit, as it has always
been my plan to do a port of libnjb to Linux (I've been lazy and haven't
gotten around to it yet).

Anyway, what I can do is point you at the library I have been building 
for the Intel Pocket Concert, which uses libusb.  The general
architecture of my Pocket Concert API is very, very similar to 
my libnjb architecture, and will show you how I went about modifying
my NJB approach to work with libusb.  The Pocket Concert library isn't
complete, but the parts you are interested in are all there.  I even
used consistent names for the source files between the Pocket Concert
and NJB libraries, which will make it ultra-easy to follow.

You can get my in-progress Pocket Concert code at:

   http://www.aracnet.com/~seagull/IPC/libipc.tar.gz

Please do not redistribute this package, as it is nowhere near ready,
and the working name I am using is very poor.  It's best if it doesn't
get out at this point.  :)


Cheers,
-+JLS

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

[Libusb-devel] libusb and libnjb

[Shaun J. <sja...@ho...>]

I've started porting libnjb (Nomad Jukebox) to libusb so as to support Linux; 
it was originally written for BSD USB. Is there any documentation on the 
libusb API, or some sample code that might help get me started?

What is absolutely mandatory to start sending control packets to a device?

usb_init
usb_find_busses
usb_find_devices
then iterate through the busses/devices and find the device you're looking 
for.
usb_open
(this is as far as I've gotten)
What comes next?

Can I now try a usb_control_msg? What requesttype do I use, and what are the 
units of timeout?

Thanks,
Shaun

Re: [Libusb-devel] ensure_ep_open()?

[<se...@ar...>]

> 
> I agree with Jasper. I don't have any other "users" of my system except for my
> wife, so I brute-forced it and chown/chmod'ed them by hand, but if it were a
> 'public' PC (in a lab or something) his solution seems more than adequate. We
> already have mechanisms like the above and /etc/fbtab that chown over devices
> to users when they are physically at the console, so these ugen* devices
> shouldn't be that much different.

There is an assumption here that USB devices are only useful when you are
on console, which I would like to avoid.  This is dangerously close to
Microsoft-style thinking.

That being said, I see Jasper's point in that one would want to avoid
having to implement SUID root merely to access /dev/ugen.  However,
putting on my Systems Administrator hat for a moment, I don't think the
solution to this is to 666 the device entries, or chown them to the user.

Instead, I suggest we 660 them, and recommend the creation of a group
(call it "usb" or whatever...the name doesn't matter) to be the group 
owner.  Then, applications that require ugen access through libusb can
be SGID to this group instead of SUID root.  This is much safer, and the
end developer won't have to worry about dropping privs...s/he can hold on to
them throughout the process lifetime.

The install process can be set up to do this, also as suggested, but I
recommend that we make this optional, prompting the suer for it, rather
than mandatory.  Again, this is the SysAdmin in me talking, who prefers
not to have my base OS configuration modified without my consent.

I still am curious, though, as to why ensure_ep_open() exists in 
freebsd.c, but has not been implemented in linux.c.  Is there a reason
for this inconsistency?


Cheers,
-+JLS

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

Re: [Libusb-devel] ensure_ep_open()?

[John R. <jjr...@ho...>]

[ On Friday, April 20, Jasper Wallace wrote: ]
> 
> I think the best way to fix this is to recommend, in the README, that users
> chown or chmod the ugen devices in such a way that non root users can access
> them.
> 
> On my system i use xdm to log in, and in my
> /usr/X11R6/lib/X11/xdm/GiveConsole i've got:

I agree with Jasper. I don't have any other "users" of my system except for my
wife, so I brute-forced it and chown/chmod'ed them by hand, but if it were a
'public' PC (in a lab or something) his solution seems more than adequate. We
already have mechanisms like the above and /etc/fbtab that chown over devices
to users when they are physically at the console, so these ugen* devices
shouldn't be that much different.

Cheers,

-Jr

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
John Reynolds         Chandler Capabilities Engineering, CDS, Intel Corporation
jre...@se...  My opinions are mine, not Intel's. Running
jjr...@ho...        FreeBSD 4.2-STABLE. FreeBSD: The Power to Serve.
http://www.reynoldsnet.org/  Come join us!!! @ http://www.FreeBSD.org/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=