libusb-devel Mailing List for libusb

On Tue, Oct 31, 2006 at 08:08:04PM +0800, Brice Rebsamen wrote:
> Hello,
> 
> I have a USB barcode scanner that acts like a keyboard: whenever a
> barcode is read it sends the code where the keyboard would normally
> write. I am writing some code in C to read from the scanner. This is
> my first application using libusb, and it is the first time I am
> working with a USB device.

USB is great in many ways, very flexible, but it may be unintuitive
to newcomers.

The keyboard-equivalent bytes sent to applications are not sent in
the clear over the bus. They're sent in blocks of data called
reports, which are specific to the USB HID device class.

Long story short there's lots of code to support this device already
and I'm not sure libusb is the best way to go. Please read recent
discussion on the list about why trying to read files from a USB
memory key with libusb is not the best way to go. Granted this is
less complicated, but the principle is the same.

What requirements do you have on portability? If you're writing a
Linux-only application, perhaps using the other end of the existing
HID/Input software in the kernel is better? Or even change your
application so that it doesn't matter which human interface device is
used to enter the barcode number. This can be a feature, think torn
barcode with numbers below intact. It will depend on your usage
scenario and requirements. USB is a lot like an expert consultant
- if you know exactly what you want it can all be incredibly
rewarding for everyone involved. If you're not sure of what you want
or fail to express it sufficiently clearly, all you get is more
problems.

If you need portability, depending on *_np() is a no-no.
(np is short for non-portable)

As for re-attaching, I'm not sure that's possible.

Another option may be the hiddev kernel interface, which also lets
the kernel hid driver remain attached. There's a libhid too, but
unfortunately it doesn't use hiddev yet. I just need some free time..
;)


//Peter

On Tue, Oct 31, 2006 at 03:04:10PM -0800, frits vanderlinden wrote:
> Suppose you want to implement in your favorite OS the function:
> 
> int libusb_open(libusb_device_id_t devid, libusb_dev_handle_t *dev);
> 
> you would need to check whether the devid is valid and not stale (the 
> device could have been hot removed between finding the devid and calling 
> libusb_open). You would also have to allocate the resources (eg. memory 
> for the dev handle, translate it to a token that is returned to the 
> application (we never return pointers to the application anymore))
> 
> Instead of duplicating all this in every OS implementation, we are 
> proposing to do all of this in the single front-end. In fact, the 
> back-end may not even have to be involved in libusb_open() and 
> libusb_close().

The 1.0 API is already like this.  Here is the implementation of
linux_open():

static int device_open(struct usbi_device *idev)
{
  int fd;

  fd = open(idev->filename, O_RDWR);
  if (fd < 0) {
    fd = open(idev->filename, O_RDONLY);
    if (fd < 0) {
      usbi_debug(1, "failed to open %s: %s", idev->filename, strerror(errno));
      return LIBUSB_FAILURE;
    }
  }

  return fd;
}

static int linux_open(struct usbi_dev_handle *hdev)
{
  struct usbi_device *idev = hdev->idev;

  hdev->fd = device_open(idev);

  list_init(&hdev->ios);

  /* FIXME: We need to query the current config here and set cur_config */

  return 0;
}


Seems pretty light to me.

- Chris

Brice Rebsamen wrote:

>Hello,
>
>I have a USB barcode scanner that acts like a keyboard: whenever a
>barcode is read it sends the code where the keyboard would normally
>write. I am writing some code in C to read from the scanner. This is
>my first application using libusb, and it is the first time I am
>working with a USB device.
>I found out how to open the usb device, detach the kernel driver and
>claim the interface. I got this information by reading the code of the
>phidget library that makes use of libusb. To read from the phidgets
>they call usb_interrupt_read. So I am doing the same but I get
>nothing, although I am managing to read 8 bytes, always the same: 0 0
>30 0 0 0 0 0
>What's wrong? I pasted my code below (I removed error checking code).
>  
>

Why do you think you should be getting 8 bytes?  Have you read the
report descriptors so you know exactly what data to expect?  Have you
read any of the USB HID Class Spec?  Some devices only return data when
you send them a request to read.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Your device may need to be initialized or may require additional work to 
get it going...  Have you tested the device?  If you have it working 
somewhere you might try using a USB sniffer to figure out what the 
device is doing - what packets are being sent to it and what packets it 
is receiving.  You might look at a keyboard driver to figure out the 
protocol...

That being said, if it acts like a keyboard, then why are you trying to 
fiddle with it on the USB level?  Couldn't you just grab your input from 
STDIN?  Or maybe there is a way to redirect the input from the scanner 
to another stream?  Seems much simpler than delving into libusb.

Ian


Brice Rebsamen wrote:
> Hello,
>
> I have a USB barcode scanner that acts like a keyboard: whenever a
> barcode is read it sends the code where the keyboard would normally
> write. I am writing some code in C to read from the scanner. This is
> my first application using libusb, and it is the first time I am
> working with a USB device.
> I found out how to open the usb device, detach the kernel driver and
> claim the interface. I got this information by reading the code of the
> phidget library that makes use of libusb. To read from the phidgets
> they call usb_interrupt_read. So I am doing the same but I get
> nothing, although I am managing to read 8 bytes, always the same: 0 0
> 30 0 0 0 0 0
> What's wrong? I pasted my code below (I removed error checking code).
>
> One more question (not so important):
> When detaching the kernel driver, it returns an error if it had been
> previously detached. How to check that and make the distinction with
> other kind of errors?
> Or:
> How to reattach the driver at the end?
>
>
>
>
> int main(){
>   usb_dev_handle *udev;
>   struct usb_bus *bus;
>   struct usb_device *dev;
>   char barcode[8];
>
>   // search for the scanner, open the device and claim interface
>   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==0x5e0 && dev->descriptor.idProduct==0x200 )
>         udev = usb_open(dev);
>   usb_detach_kernel_driver_np(udev, 0);
>   usb_claim_interface(udev, 0);
>
>   //prompt scanner until we get 8 bytes.
>   while( usb_interrupt_read(udev,1,barcode,8,1000)!=8 );
>
>   int i;
>   printf("barcode: ");
>   for( i=0; i<8; i++ ) printf("%u ",barcode[i]);
>   printf("\n");
>
>   usb_release_interface(udev, 0);
>   usb_close(udev);
>   return 1;
> }
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
>
>   

Peter Stuge wrote:

>> We would like to take this opportunity to discuss some other ideas:
>>
>> - Take a front-end and back-end approach to the implementation.
>> The front-end should do all detailed sanity checks on all calls and 
>> perform most of the error handling.
>> This would allow OS-specific back-ends to be very thin, easy to
>> implement and avoids duplication of code.
> 
> How is this different from the current way of OS abstraction? (One
> file per OS.) Note I don't know the code in detail.
> 
Suppose you want to implement in your favorite OS the function:

int libusb_open(libusb_device_id_t devid, libusb_dev_handle_t *dev);

you would need to check whether the devid is valid and not stale (the 
device could have been hot removed between finding the devid and calling 
libusb_open). You would also have to allocate the resources (eg. memory 
for the dev handle, translate it to a token that is returned to the 
application (we never return pointers to the application anymore))

Instead of duplicating all this in every OS implementation, we are 
proposing to do all of this in the single front-end. In fact, the 
back-end may not even have to be involved in libusb_open() and 
libusb_close().

Sun also needs the frontend because with one libusb we would like to 
support Solaris *and* Sunray (thin client). We have successfully done 
this for libusb.0.1.0.*.

> 
>> - Man pages should be written while the implementation is in
>> progress and will be much more detailed than for libusb.0.1.0.*.
>> The man pages should clearly document all the corner cases, etc.
> 
> Does there have to be any corner cases left? :)
> 
There will always be races (eg. the device disappears during a transfer 
from the device to the host. do we return the data transferred so far or 
  just tell the caller the request failed because the device went away).

> Of course I agree that documentation is a good thing.
> 
> 
>> - There should be an exhaustive test/compliance suite that will
>> prove that a backend is 100% compliant with the API and ensure that
>> all backends behave exactly the same. An application should never
>> see any differences between OSs.
> 
> This is obviously the purpose of libusb. Please expand on your
> thoughts about the frontend/backend split. I don't know if I like it.
> 
see above, I hope you like it

By having most of the implementation in the front-end, we will get for 
"free" that each OS implementation behave very similar in many respects.

> 
>> There should be an standard USB test device (ezusb?) which allows
>> full verification of all error recovery paths.
> 
> Great idea, I think we want more than one. At least one per speed
> (low/full/high) and 1.1 as well as 2.0 would be nice. I don't know

absolutely

> how many IP USB implementations are out there (in ASICs) but it would
> be very nice to have test devices implemented with several different
> microcontrollers.

the idea of the test device is that it really behaves very poorly and 
unpredictably. It should never crash libusb or the kernel and it should 
in theory provide complete code coverage during the testing

> 
> 
>> - It might be possible to emulate libusb.0.1.0.* on libusb1.0.
>> Some applications work quite well on the old API and by emulating
>> the libusb.0.1.0.* API on the libusb1.0 implementation, these
>> applications will continue to be supported and will run on a more
>> robust libusb implementation.
> 
> I think backwards compatibility is a big deal for the adoption rate.
> It will also make transitioning from 0.1 to 1.0 feel easier.
> 
> 
exactly. Forcing applications to migrate is rarely successful. Having to 
maintain libusb.0.1.0.x and libusb1.0 is a waste of our precious cycles.

cheers


fritS

Ian MacLennan wrote:

>I'm sure you could port libusb to GNU Hurd...  but I would imagine you 
>would have to implement a lot of the stuff that is done at the OS level 
>into your implement of libusb.
>  
>

A port would not be possible without implementing a host controller
driver.  That's more than just a port.  That's fundamental architecture.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

On Tue, Oct 31, 2006 at 01:00:01PM -0800, frits vanderlinden wrote:
> Sun would like to contribute people and resources to both the linux
> and Solaris implementation to finish the libusb1.0 work in the
> coming months.

Cool.


> We would like to take this opportunity to discuss some other ideas:
> 
> - Take a front-end and back-end approach to the implementation.
> The front-end should do all detailed sanity checks on all calls and 
> perform most of the error handling.
> This would allow OS-specific back-ends to be very thin, easy to
> implement and avoids duplication of code.

How is this different from the current way of OS abstraction? (One
file per OS.) Note I don't know the code in detail.


> - Man pages should be written while the implementation is in
> progress and will be much more detailed than for libusb.0.1.0.*.
> The man pages should clearly document all the corner cases, etc.

Does there have to be any corner cases left? :)

Of course I agree that documentation is a good thing.


> - There should be an exhaustive test/compliance suite that will
> prove that a backend is 100% compliant with the API and ensure that
> all backends behave exactly the same. An application should never
> see any differences between OSs.

This is obviously the purpose of libusb. Please expand on your
thoughts about the frontend/backend split. I don't know if I like it.


> There should be an standard USB test device (ezusb?) which allows
> full verification of all error recovery paths.

Great idea, I think we want more than one. At least one per speed
(low/full/high) and 1.1 as well as 2.0 would be nice. I don't know
how many IP USB implementations are out there (in ASICs) but it would
be very nice to have test devices implemented with several different
microcontrollers.


> - It might be possible to emulate libusb.0.1.0.* on libusb1.0.
> Some applications work quite well on the old API and by emulating
> the libusb.0.1.0.* API on the libusb1.0 implementation, these
> applications will continue to be supported and will run on a more
> robust libusb implementation.

I think backwards compatibility is a big deal for the adoption rate.
It will also make transitioning from 0.1 to 1.0 feel easier.


//Peter

Many of us would really like libusb1.0 to get off the ground for the 
obvious reasons that it will be more robust, multi-threaded and has a 
much more powerful API than libusb 0.1.0.x. It might trigger a renewed 
interest in libusb and a wave of more applications, hopefully.
Today there is only an incomplete implementation on linux in subversion.

Paul Klissner and I worked with Johannes for most of 2005 to put 
together the libusb 1.0 API (refer to libusb.h).
This was by no means considered the final 1.0  API as we needed more 
implementation experience on various OSs and some applications ported to 
the new API.

[I can probably answer most questions on the motivation behind most of 
the interfaces in libusb.h so feel free to send your questions].

Sun would like to contribute people and resources to both the linux and 
Solaris implementation to finish the libusb1.0 work in the coming months.

We would like to take this opportunity to discuss some other ideas:

- Take a front-end and back-end approach to the implementation.
The front-end should do all detailed sanity checks on all calls and 
perform most of the error handling.
This would allow OS-specific back-ends to be very thin, easy to
implement and avoids duplication of code.

- Man pages should be written while the implementation is in progress 
and will be much more detailed than for libusb.0.1.0.*. The man pages 
should clearly document all the corner cases, etc.

- There should be an exhaustive test/compliance suite that will prove
that a backend is 100% compliant with the API and ensure that all
backends behave exactly the same. An application should never see any
differences between OSs.
There should be an standard USB test device (ezusb?) which allows full
verification of all error recovery paths.

- It might be possible to emulate libusb.0.1.0.* on libusb1.0.
Some applications work quite well on the old API and by emulating the 
libusb.0.1.0.* API on the libusb1.0 implementation, these applications 
will continue to be supported and will run on a more robust libusb 
implementation.

comments?


The Sun libusb team:

Sophia Li (lead, solaris implementation)
Xiaoxin Liu (linux implementation)
Paul Klissner (sunray (thin client) implementation)
Frits Vanderlinden (architect)

At Tue, 31 Oct 2006 20:22:11 +0200 Constantine Kousoulos <wu...@fr...> wrote:

> 
> Tim Roberts wrote:
> > Sorry, this is impossible.  GNU Hurd simply does not support USB at this
> > time...
> > 
> 
> Well yes, I'm aware of that. I was just hoping to change that fact. :)
> 
> > On all the operating systems it supports, libusb is little more than a
> > pretty wrapper over a standard kernel driver.  On Linux, that happens to
> > be the "usbfs" driver.  GNU Hurd has no kernel support for USB at all.
> > 
> 
> At first i thought of libusb as a user-space implementation of the
> usb specification. I have to admit that i was confused by the web
> site's declaration: "It's aim is to create a library for use by
> user level applications to access USB devices regardless of OS".
> Well, the os does matter, especially if your're running an os that
> has no support for usb.

I would guess that the statement above is poorly worded.  Maybe
something like:

"It's aim is to create a library for use by user level applications to
access USB devices regardless of the OS's driver API." or something like
that.  

That is the user-level code would not end up with piles of
#ifdef/#endif blocks all over the place. Instead one would have a
(standard) set of libusb calls, for which there would be OS-specific
libraries that would do the right thing (whatever that would be) for
each OS.  All of the OS specific code would be 'hidden' away from the
user-mode application code and would be in a separate shared library. 

In the case of GNU Hurd, all of the functions would be vacant at
present, since there is no kernel API for USB devices.  

> 
> 
> Thanks,
> Constantine
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
> 
>                                                                     

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Linux Installation and Administration
http://www.deepsoft.com/  -- Web Hosting, with CGI and Database
he...@de...       -- Contract Programming: C/C++, Tcl/Tk
                                                                            

Constantine Kousoulos wrote:
> Tim Roberts wrote:
>   
>> Sorry, this is impossible.  GNU Hurd simply does not support USB at this
>> time...
>>     
>
> Well yes, I'm aware of that. I was just hoping to change that fact. :)
>
>   
>> On all the operating systems it supports, libusb is little more than a
>> pretty wrapper over a standard kernel driver.  On Linux, that happens to
>> be the "usbfs" driver.  GNU Hurd has no kernel support for USB at all.
>>     
>
> At first i thought of libusb as a user-space implementation of the
> usb specification. I have to admit that i was confused by the web
> site's declaration: "It's aim is to create a library for use by
> user level applications to access USB devices regardless of OS".
> Well, the os does matter, especially if your're running an os that
> has no support for usb.
>   

You might want to troll about this list's archives.  A few things you'll 
note:

    * libusb is currently "stable" at version 0.1.12
    * there is a libusb 1.0 development branch which is somewhat
      moribund at the moment; its goal is/was to clean up some of the
      perceived and real flaws of the 0.1.x API and support
    * there is little-to-no buffering in libusb itself; as Tim says,
      it's a convenient wrapper around the OS support, which varies
      quite a bit
    * the 0.1.x version achieves platform support by compiling a loose
      "core" of source plus an OS-specific bit of glue; the 1.0 version
      attempts a seemingly more elegant solution by looking for an
      appropriately-named shared-object to handle the OS-specific work,
      but this in itself requires services that may not be universally
      available (e.g., to an embedded, non-*ix OS)

I am hoping to get some Round Tuits to help make 1.0 come alive again.  
One of the key aspects to the newer API is that it is (more nearly) 
reentrant and thread-safe.  One of the challenges will be to not break 
older 0.1.12 applications (too badly) and hopefully to even 
inter-operate safely with a mixed-version user base.

-Del

well...  yes...  I suppose it is OS dependent...  but I think context is 
important...  this statement means that libusb will be deployed on 
multiple OSs, and where libusb is deployed, it can be used in a (mostly) 
platform independent way.  For example, I don't think anybody would 
expect libusb to work on their DOS 3.1 machine, or on their C64.

I'm sure you could port libusb to GNU Hurd...  but I would imagine you 
would have to implement a lot of the stuff that is done at the OS level 
into your implement of libusb.

Ian


Constantine Kousoulos wrote:
> Tim Roberts wrote:
>   
>> Sorry, this is impossible.  GNU Hurd simply does not support USB at this
>> time...
>>
>>     
>
> Well yes, I'm aware of that. I was just hoping to change that fact. :)
>
>   
>> On all the operating systems it supports, libusb is little more than a
>> pretty wrapper over a standard kernel driver.  On Linux, that happens to
>> be the "usbfs" driver.  GNU Hurd has no kernel support for USB at all.
>>
>>     
>
> At first i thought of libusb as a user-space implementation of the
> usb specification. I have to admit that i was confused by the web
> site's declaration: "It's aim is to create a library for use by
> user level applications to access USB devices regardless of OS".
> Well, the os does matter, especially if your're running an os that
> has no support for usb.
>
>
> Thanks,
> Constantine
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>
>
>   

Tim Roberts wrote:
> Sorry, this is impossible.  GNU Hurd simply does not support USB at this
> time...
> 

Well yes, I'm aware of that. I was just hoping to change that fact. :)

> On all the operating systems it supports, libusb is little more than a
> pretty wrapper over a standard kernel driver.  On Linux, that happens to
> be the "usbfs" driver.  GNU Hurd has no kernel support for USB at all.
> 

At first i thought of libusb as a user-space implementation of the
usb specification. I have to admit that i was confused by the web
site's declaration: "It's aim is to create a library for use by
user level applications to access USB devices regardless of OS".
Well, the os does matter, especially if your're running an os that
has no support for usb.


Thanks,
Constantine

Constantine Kousoulos wrote:

>I'm interested in porting libusb to the GNU Hurd operating system. 
>  I tried to 'configure' on GNU Hurd but it fails because it 
>doesn't recognise Hurd as an acceptable host system.
>
>Can someone give me a few pointers to the os-specific parts of 
>libusb so that i can add some Hurd support?
>  
>

Sorry, this is impossible.  GNU Hurd simply does not support USB at this
time.

On all the operating systems it supports, libusb is little more than a
pretty wrapper over a standard kernel driver.  On Linux, that happens to
be the "usbfs" driver.  GNU Hurd has no kernel support for USB at all.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Hello,

I'm interested in porting libusb to the GNU Hurd operating system. 
  I tried to 'configure' on GNU Hurd but it fails because it 
doesn't recognise Hurd as an acceptable host system.

Can someone give me a few pointers to the os-specific parts of 
libusb so that i can add some Hurd support?

Thanks,
Constantine

Hello,

I have a USB barcode scanner that acts like a keyboard: whenever a
barcode is read it sends the code where the keyboard would normally
write. I am writing some code in C to read from the scanner. This is
my first application using libusb, and it is the first time I am
working with a USB device.
I found out how to open the usb device, detach the kernel driver and
claim the interface. I got this information by reading the code of the
phidget library that makes use of libusb. To read from the phidgets
they call usb_interrupt_read. So I am doing the same but I get
nothing, although I am managing to read 8 bytes, always the same: 0 0
30 0 0 0 0 0
What's wrong? I pasted my code below (I removed error checking code).

One more question (not so important):
When detaching the kernel driver, it returns an error if it had been
previously detached. How to check that and make the distinction with
other kind of errors?
Or:
How to reattach the driver at the end?




int main(){
  usb_dev_handle *udev;
  struct usb_bus *bus;
  struct usb_device *dev;
  char barcode[8];

  // search for the scanner, open the device and claim interface
  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==0x5e0 && dev->descriptor.idProduct==0x200 )
        udev = usb_open(dev);
  usb_detach_kernel_driver_np(udev, 0);
  usb_claim_interface(udev, 0);

  //prompt scanner until we get 8 bytes.
  while( usb_interrupt_read(udev,1,barcode,8,1000)!=8 );

  int i;
  printf("barcode: ");
  for( i=0; i<8; i++ ) printf("%u ",barcode[i]);
  printf("\n");

  usb_release_interface(udev, 0);
  usb_close(udev);
  return 1;
}

mockingbird squibb

Up On the News - GSNH closes Up Friday, After-Market News Release - Get GSNH Quote Here. hone.
http://moneycentral.msn.com/detail/stock_quote?Symbol=gsnh

After weeks of speculation it's finally here, and the news is even bigger than we thought. short.

We first knew something was up with GSNH when news came out Thursday regarding Drill LOMT #1. But GSNH really popped up on our radar with Friday's After-Market news. GSNH has announced its partners for the LOMT #1 sidetrack well and you are not going to believe who they are. brinkmanship.

GSNH Names Partners for LOMT #1 Sidetrack Well wartime.
Friday October 27, 4:05 pm ET telescopic.
HOUSTON, Texas--(BUSINESS WIRE) - GSNH announces...has awarded drilling services for the LOMT #1 Sidetrack well to the following providers: backspace
* Patterson-UTI (Nasdaq: PTEN), Revenue: 2.23 billion, UP 63.30% fermentation
* Schlumberger (NYSE: SLB), Revenue: 17.90 billion, UP 34.00% alewife
* Halliburton (NYSE: HAL), Revenue: 22.90 billion, UP 13.40% spartan

Oct. 27, 2006 (BUSINESS WIRE) - GSNH Names Partners for Sidetrack Well... russia
http://biz.yahoo.com/bw/061027/20061027005324.html?.v=1

GSNH has been releasing steady news worldwide, from Yahoo Finance, AOL, & MSN Money to Marketwatch & Bloomberg---even the NYSE & the NASDAQ have gotten in on the action. Exposure for GSNH is expansive. The increased frequency of news led us to believe that something big was coming for GSNH, and as usual, we were dead-on right. pearlite

Oct. 26, 2006 (BUSINESS WIRE) – GSNH to Drill LOMT #1... whither.
http://money.aol.com/news/articles/_a/greater-sooner-holdings-inc-to-drill/n20061026162609990029

Oct. 12, 2006 (BUSINESS WIRE) – GSNH Reports Drilling Success... transplantation.
http://www.marketwatch.com/News/Story/Story.aspx?guid={05206016-17D5-4077-B8A3-3D8A763487E2}&siteid=mktw&sid=2133723&symb=

Oct. 11, 2006 (BUSINESS WIRE) – GSNH Announces the Anthony 33... conglomerate.
http://news.moneycentral.msn.com/ticker/article.asp?Feed=BW&Date=20061011&ID=6094112&Symbol=US:GSNH

Oct. 4, 2006 (BUSINESS WIRE) – GSNH...285 million in Probable Reserves... westfield.
http://bloomberg.com/apps/news?pid=conewsstory&refer=conews&tkr=GSNH:US&sid=a6F2jO13PWCU

Friday's After-Market news on GSNH and its newfound partnership with these major corporations (over 43 billion in revenue combined) is just the beginning. We believe that there is even bigger news coming, and as always, we are bringing you the news ahead of time, ahead of everyone else, and ahead of a major spike in GSNH stock price.

popish those deacon

The accumulation of positions by those in the know has shot
A_U_N_I up 33% in a few short days.  We hope you all got in
early like we told you to, and are enjoying your good fortune.
But even if you didn't don't worry because the big announcement
has yet to be made.  Monday, October 30 may be your last chance
before this thing triples.  Don't hesitate.

Price: O.85
Projected: 2.3O
Rating: 5/5

This is the break you've been waiting for!  Spice up your
holdings with A_U_N_I and WIN!

Hello all, I am trying to transfer large amounts of data at the  
USB2.0 speed.  Every once in a while a length of data points seems to  
be totally wrong.  The data is sent at a constant rate, and the  
source does NOT send bad data (I have verified this).

Here is what I am doing:

-Configuring my device correctly. usb_open(), usb_claim_interface()
-Requesting 20KB from usb_bulk_read in one call from endpoint 6

bytes_read = usb_bulk_read(drx_dev_handle,6,(char *) epbuf,sizeof 
(epbuf),1000);
// short epbuf[1024*20];

I get back 1024*20 = 20480 for bytes_read, everything looks perfect.

The max packet size of EP6 is 512 bytes?  So I am requesting 20KB  
from EP6 which has max packet size of 512 bytes.

Does anything look fishy here?  Like I said, data every once in a  
while looks bad.  By once in a while, I don't mean periodic.

I am requesting such large sizes of data so I don't have to worry  
about multiple URB's which will cause additional overhead and slow my  
transfer rate right?

Here is how my device is configured:

Dev #39: CCAR - Digital Receiver
   - Serial Number: v1.0
   wTotalLength:         32
   bNumInterfaces:       1
   bConfigurationValue:  1
   iConfiguration:       0
   bmAttributes:         c0h
   MaxPower:             0
     bInterfaceNumber:   0
     bAlternateSetting:  0
     bNumEndpoints:      2
     bInterfaceClass:    255
     bInterfaceSubClass: 255
     bInterfaceProtocol: 255
     iInterface:         1
       bEndpointAddress: 02h
       bmAttributes:     02h
       wMaxPacketSize:   512
       bInterval:        1
       bRefresh:         0
       bSynchAddress:    0
       bEndpointAddress: 86h
       bmAttributes:     02h
       wMaxPacketSize:   512
       bInterval:        1
       bRefresh:         0
       bSynchAddress:    0

I have a picture of a data set where data is bad, I can send it if  
anyone would like.

Any ideas more than welcome,
Lloyd

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<img alt="" src="cid:par...@ne..." height="405"
 width="597"><br>
when IAm walking home from the office toward Penn Station and I see
throngs of people standing outside Avalon and Madison Square Garden
hoping to score . might not happen if women wore a hijab and stayed at
home.<br>
If you order other products in the same order, we will ship you the rest
products first. Can items listed here make great gifts? Although she has
the opportunity to leave, she stays, after her home is bombed, after .
Eight dish garden table decorations were also given away.<br>
Send questions about your lawn, garden, plants, or insects to . Includes
a bonus activity guide for learning extensions. Then she discovered
Tansi and is happy to call this home. Can items listed here make great
gifts?<br>
Although she has the opportunity to leave, she stays, after her home is
bombed, after .<br>
The Ballarat Botanic Gardens where they are staged has been declared
off-limits. Sitemap Generator can create sitemaps from URL lists,
webserver directories, or from access logs and notify Google. The
shipping charge for the second shipment will apply. Pinyin is marked on
the new words.<br>
Includes a list of hands-on activities to make learning about Chinese
festivals fun and colorful.<br>
engines to suit their tastes and preferences; be it cooking, gardening,
music, the .<br>
The Head Cancer Wizard is to retire. This volume chronicles the
development of Chinese civilization from Neolithic times, when
agriculture revolutionized society, to the early first century A. Pinyin
is marked on the new words.<br>
He said she had a beautiful garden with a fountain, and they enjoyed
plenty of feeders around their Summit home.<br>
Blackcurrant gin, regurgitated on a neighbour's garden in Gore was not a
good look.<br>
Then she discovered Tansi and is happy to call this home.<br>
He said she had a beautiful garden with a fountain, and they enjoyed
plenty of feeders around their Summit home.<br>
Authorities say Jimenez,a day laborer who lived with his brother's
family in Morristown, beat the boy with a gardening tool to keep him
from telling anyone. The Ballarat Botanic Gardens where they are staged
has been declared off-limits.<br>
His favorite ghost story picks on home video include AThe Sixth
Sense,AThe . Then she discovered Tansi and is happy to call this home.
Can items listed here make great gifts?<br>
might not happen if women wore a hijab and stayed at home.<br>
<br>
</body>
</html>

Muthukumaran wrote:
> Thank you Robert and Peter,
>                   Ya i got the output as Vendor details and Interface 
> no etc. using testlibusb.c, But is there any way to Access the files 
> in USB 2.0 containing txt.file and .mp3 file and .pdf files..etc, with 
> out going by mounting the device by
>  " mount/ dev/sdb/ media/usbdriver " and so the pgm below will list 
> the files in usbdrive:

To help clarify (though others have been patiently doing so for a while):

The USB interface (and so libusb)  *has no concept* of "files" on 
storage media.

The USB layer only gives you access to individual sectors on the disk.

The relationship between "files" on a USB disk and the raw storage (the 
sectors) is not understood by the USB layer.

It is handled by a layer of software -- usually the filesystem in the 
operating system -- that *uses* the USB layer to get to the raw storage.

-- 
Ned Konz

Hi,

On Thu, Oct 26, 2006 at 09:42:26AM -0400, John Lenmac wrote:
>     i =3D usb_control_msg( udev, 0x22, 0x09, 2, 0, buffer, 0, 5000 );

Why is buffer length 0?

> Also, while I'm at it...  The packet I am trying to send is read as=20
> follows under USB SnoopyPro...
> 34    out down    n/a    0.259    CLASS_INTERFACE    ad ef 8d 00 00 00=20
> 00 00  =20
> URB Header (length: 80)
> SequenceNumber: 34
> Function: 001b (CLASS_INTERFACE)
> PipeHandle: 00000000
>=20
> SetupPacket:
> 0000: 22 09 00 02 00 00 00 00
> bmRequestType: 22
>   DIR: Host-To-Device
>   TYPE: Class
>   RECIPIENT: Endpoint
> bRequest: 09=20
>=20
>=20
> TransferBuffer: 0x00000008 (8) length
> 0000: ad ef 8d 00 00 00 00 00

I can't read the output of USB SnoopyPro so I don't undesratnd where
you got the fourth and fifth arguments to usb_control_msg call.

If you used usbsnoop 1.8 instead you could read
http://iki.fi/lindi/usb/usbsnoop.txt to learn how to automatically
convert the log file into a C program that calls usb_control_msg with
proper arguments.

best regards,
Timo Lindfors

Hi there,

I am trying to get a Windows targetted device to work on Linux.  It is 
an HID device.  I have been able to get all the descriptors from it and 
stuff.  I can also set my configuration, my alt, and claim the 
interface.  But when I try to send a control message (I'll include the 
call below) I get the error (if I print out the results of 
usb_stderror() ): error sending control message: No such file or 
directory)...  anybody have any ideas?  Running on FC5, and files seem 
to exist in both proc/bus and dev/bus.

    i = usb_control_msg( udev, 0x22, 0x09, 2, 0, buffer, 0, 5000 );
    if (i >= 0) {
      printf( "sent control message! %d\n", i );
    } else {
      printf( "Control message failed! %d %s\n", i, usb_strerror() );
    }

Also, while I'm at it...  The packet I am trying to send is read as 
follows under USB SnoopyPro...
34    out down    n/a    0.259    CLASS_INTERFACE    ad ef 8d 00 00 00 
00 00   
URB Header (length: 80)
SequenceNumber: 34
Function: 001b (CLASS_INTERFACE)
PipeHandle: 00000000

SetupPacket:
0000: 22 09 00 02 00 00 00 00
bmRequestType: 22
  DIR: Host-To-Device
  TYPE: Class
  RECIPIENT: Endpoint
bRequest: 09 


TransferBuffer: 0x00000008 (8) length
0000: ad ef 8d 00 00 00 00 00


Am I sending the right control_msg?

Hope this is clear and any help is greatly appreciated!
John

Hi,

On Wed, Oct 25, 2006 at 09:50:40AM -0700, Tim Roberts wrote:
> I have written twice in the last two weeks about the steps needed to
> interact with a USB mass storage device.  It is not a task to be
> undertaken lightly.  If you want to experiment with USB devices, you
> need to choose another kind of device.

I can't understand the original problem either but

http://iki.fi/lindi/usb/usb-storace.c

is a quick'n'dirty program to dump sectors from USB mass storage
devices. I wrote it because I wanted to learn and because I have a
memory card reader that causes linux to sometimes put processes to
eternal "disk sleep" state when I try to access the card.

best regards,
Timo Lindfors

Tim Roberts wrote:

> If you want to experiment with USB devices, you need to choose
 > another kind of device.

Well, no, this guy could disable the USB mass storage class driver
in the kernel and then just play around with the device via libusb
if he (she?) wants to learn about it. However, given the level of
questions being asked here and the fact that this person doesn't
understand that there is a kernel driver that is claiming the device,
I suspect that using a simpler USB device might be more productive
as a learning experience.

mike

-- 
Mic...@su...                         Sun Ray Product Engineering

  I don't speak for my employer. My opinions are not necessarily those of
      Sun Microsystems, Inc. or any of its wholly-owned subsidiaries.

kourla ashok kumar reddy wrote:

> when i use below program to read data from USB mass
> storage device(pendrive) iam getting following error.

The salient point in this discussion is why do you want to write
a liusb-based driver to read data from a USB mass-storage device
when there already exists Linux (and Solaris) kernel drivers and
filesystem code that will do that for you?

You haven't answered that question. What you did say was:

             "i am device driver programmer."

which is fine as it goes, so am I, however I don't spend my time
trying to re-implement USB mass-storage class drivers or kernel
filesystem code.

Is there something that isn't working properly in the existing
implementations, or are you just trying to learn how to do this
stuff (which is a fine thing to do)?

Please keep replies on-list.

mike

-- 
Mic...@su...                         Sun Ray Product Engineering

  I don't speak for my employer. My opinions are not necessarily those of
      Sun Microsystems, Inc. or any of its wholly-owned subsidiaries.