Alexander Baldeck | 3 Dec 2004 05:17
Picon

usb_control_msg results in broken pipe error

Hello,

unfortunately the documentation on libusb isn't explaining things very
well and my time is too limited  to go through the whole usb specs etc.
i've already done 2 hours of googleing with no relevant results.
i will now try to explain my scenario and hope somebody is kind enough
to help me out a bit. :)

i'm working on a driver for a very simple device. basicly it's only
glasses with leds on each side which i am to turn on and off plus
regulate the brightness of them.

so the driver only needs 2 functionalities:

1) turn LEDs on
2) set brightness

it is supposed to make the device work in at least GNU/Linux and MacOS
X. in order to do that i have been given the control codes & vendor
commands. now i need to find my way to send them to the device. i do
only need 1 byte userdata per request.

here's what i got so far:

############################################################################

#include <usb.h>
#include <stdio.h>

#define MM_VID      0x152A
(Continue reading)

Stephan Meyer | 3 Dec 2004 17:50
Picon

Re: usb_control_msg results in broken pipe error

> ret = usb_control_msg(mm_devs[i].handle, 0x81, REQ_WRITE, CMD_WRITE, 0, buffer, 4, 5000);

Vendor specific control messages are described in section 9.3 of the specs. 
The 'bmRequestType' parameter of the control message should be initialized
as follows:

D7: Data transfer direction
0 = Host-to-device
1 = Device-to-host

D6...5: Type
0 = Standard
1 = Class
2 = Vendor
3 = Reserved

D4...0: Recipient
0 = Device
1 = Interface
2 = Endpoint
3 = Other
4...31 = Reserved 

So, in your case I would try to call the function this way:

usb_control_msg(mm_devs[i].handle, 
                            USB_ENDPOINT_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE, ....); 

The values you have to use for 'bRequest', 'wValue', and 'wIndex' depend on your device.

(Continue reading)

C.J. Steele | 4 Dec 2004 07:21

MacOS X can't usb_claim_interface()

I've got MacOS X (10.3.6) with gcc 3.3 (20030304) and libusb 0.1.8.  I'm unable
to usb_claim_interface() on my device.  I turned debugging up and tried to
claim the device and I got:

usb_os_open: 0c70:0750
usb_set_configuration: called for config 1
usb_claim_interface: called for interface 0
Interface 0 of device is 0x108f
claim_interface: Interface 0 of device from QueryInterface is 0x501460
USB error: claim_interface(USBInterfaceOpen): another process has device opened
for exclusive access
USB error: usb_claim_interface: couldn't claim interface

..this, of course, begs a couple of questions:
1) How can I tell what other process has the device claimed?  From what I
understand, whether or not a device is claimed is a function of
operating-system level and that libusb interfaces with the os to claim it,
etc...  How can I examine the OS?  I've got USB\ Prober.app, and I've tried to
use that, but I can't see what process has the devices claimed.  Any tips?
2) I presume someone else has gotten libusb to claim an interface on MacOS X
before?  Here's the code that actually tries to claim the interface...

int thum_init_thum( usb_dev_handle * indev_h )
{
    int status = usb_set_configuration( indev_h, 1 );
    if( status < 0 )
    {
        /* they failed to even configure the device. */
        return -1;
    } else {
(Continue reading)

Charles Lepple | 4 Dec 2004 16:49
Picon

Re: MacOS X can't usb_claim_interface()

On Sat,  4 Dec 2004 00:21:46 -0600, C.J. Steele
<csteele <at> forwardsteptech.com> wrote:
> I've got MacOS X (10.3.6) with gcc 3.3 (20030304) and libusb 0.1.8.  I'm unable
> to usb_claim_interface() on my device.  I turned debugging up and tried to
> claim the device and I got:

You beat me to it... I was just about to try and distill my code down
to a test case to confirm the same problem on my machine (also
10.3.6).

> ..this, of course, begs a couple of questions:
> 1) How can I tell what other process has the device claimed?  From what I
> understand, whether or not a device is claimed is a function of
> operating-system level and that libusb interfaces with the os to claim it,
> etc...  How can I examine the OS?  I've got USB\ Prober.app, and I've tried to
> use that, but I can't see what process has the devices claimed.  Any tips?

I don't know the answer, but I've been looking at a possible OS X
solution to what libhid does on Linux: it tries to open the device,
and if it fails, it uses another call to force the other process(es)
to relinquish control.

> 2) I presume someone else has gotten libusb to claim an interface on MacOS X
> before?

I think this may have surfaced with a recent revision of the
underlying USB driver.

> It seems as though I can usb_set_configuration the device, which if I'm not
> mistaken also tries to do a claim_interface (not usb_claim_interface) as well,
(Continue reading)

C.J. Steele | 5 Dec 2004 03:54

Re: MacOS X can't usb_claim_interface()

Working on the assumption that there was something different between OS 10.3.0
and 103.6, I did a fresh install of 10.3.0, recompiled and ran the program
again... with the same result.  I'm not bitter about the two hours of my life
that I'll never have back... really, I'm not.  I would comment that I did
verifythat there are different versions of the affected kernel extentions,
etc., installed on the machine at present, so its not like there are remnant
components from the old system install.

My quesion at this point is: has anyone been successful with libusb on 10.3?  If
so, would they be willing to share a code snippet or test application (other
than testlibusb, which has no usb_claim_interface() calls)?

Any other ideas?  If it'd be useful, I'd be happy to post the complete
program...

Ciao,
-C

Quoting Charles Lepple <clepple <at> gmail.com>:

> On Sat,  4 Dec 2004 00:21:46 -0600, C.J. Steele
> <csteele <at> forwardsteptech.com> wrote:
> > I've got MacOS X (10.3.6) with gcc 3.3 (20030304) and libusb 0.1.8.  I'm
> unable
> > to usb_claim_interface() on my device.  I turned debugging up and tried to
> > claim the device and I got:
>
> You beat me to it... I was just about to try and distill my code down
> to a test case to confirm the same problem on my machine (also
> 10.3.6).
(Continue reading)

Peter Stuge | 5 Dec 2004 18:04

Re: MacOS X can't usb_claim_interface()

On Sat, Dec 04, 2004 at 08:54:43PM -0600, C.J. Steele wrote:
> My quesion at this point is: has anyone been successful with libusb
> on 10.3? 

Sure.

> If so, would they be willing to share a code snippet or test
> application (other than testlibusb, which has no
> usb_claim_interface() calls)?

...
  usb_init();
  usb_find_busses();
  usb_find_devices();
  busses=usb_get_busses();

  for(bus=busses;bus;bus=bus->next)
    for(dev=bus->devices;dev;dev=dev->next)
      if(dev->descriptor.idVendor==VID&&dev->descriptor.idProduct==PID)
        goto found;

  fprintf(stderr,"device not found!\n");

  return 1;

found:
  dh=usb_open(dev);
  if((i=usb_set_configuration(dh,1))<0) {
    printf("usb_set_configuration=%d\n",i);
    return 1;
(Continue reading)

C.J. Steele | 5 Dec 2004 23:38

Re: MacOS X can't usb_claim_interface()

Peter;

I added the following to the head of your code:

#include <usb.h>
#include <stdio.h>

#define VID 0x0C70
#define PID 0x0750
#define DEBUG 100

int main()
{
  usb_set_debug( DEBUG );

  struct usb_bus *busses;
  struct usb_bus *bus;
  struct usb_device *dev;
  usb_dev_handle *dh;
  int i;
  int j;
  unsigned int ep;
  char buf[2] = { 0, 0 };

..then compiled it with... `gcc -Wall -o tst test.c -I/usr/local/include -lusb
-lIOkit -framework CoreFoundation` and got the following on execution:

<snip>
usb_os_close: 05ac:8006
usb_os_open: 0c70:0750
(Continue reading)

C.J. Steele | 6 Dec 2004 13:42

Re: MacOS X can't usb_claim_interface()

..yes, I'm replying to my own post.  ;-)

I tried a different piece of hardware, and it appears that the problem is not my
code, but rather the hardware.  That's the problem with custom-built hardware. 
Sooo, I guess I to back to the design engineer and get that issue sorted out
first.  Thanks for all the feedback!

Ciao,
Corey

Quoting "C.J. Steele" <csteele <at> forwardsteptech.com>:

> Peter;
>
> I added the following to the head of your code:
>
> #include <usb.h>
> #include <stdio.h>
>
> #define VID 0x0C70
> #define PID 0x0750
> #define DEBUG 100
>
> int main()
> {
>   usb_set_debug( DEBUG );
>
>   struct usb_bus *busses;
>   struct usb_bus *bus;
>   struct usb_device *dev;
(Continue reading)

Peter Stuge | 6 Dec 2004 13:53

Re: MacOS X can't usb_claim_interface()

On Mon, Dec 06, 2004 at 06:42:14AM -0600, C.J. Steele wrote:
> ..yes, I'm replying to my own post.  ;-)
> 
> I tried a different piece of hardware, and it appears that the
> problem is not my code, but rather the hardware.  That's the
> problem with custom-built hardware. 
> Sooo, I guess I to back to the design engineer and get that issue
> sorted out first.  Thanks for all the feedback!

Could be the descriptors make the device get picked up by some OS
class drivers.

Anyway, you the software engineer should work closely with the
hardware designer to specify the descriptors. I think that's actually
the largest part of the job, if you want to make something really
interoperable.

//Peter

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/
C.J. Steele | 6 Dec 2004 17:38

Re: MacOS X can't usb_claim_interface()

Peter & Charles

Truns out its a HID device so the OS's HID driver is grabbing it.  I'll grab
libhid and go from there.

I appreciate the help you have both been and the patience you have had with all
of this.  I think I'm heading down the right path now.

Thanks,
Corey

Quoting Peter Stuge <stuge-libusb <at> cdy.org>:

> On Mon, Dec 06, 2004 at 06:42:14AM -0600, C.J. Steele wrote:
> > ..yes, I'm replying to my own post.  ;-)
> >
> > I tried a different piece of hardware, and it appears that the
> > problem is not my code, but rather the hardware.  That's the
> > problem with custom-built hardware.
> > Sooo, I guess I to back to the design engineer and get that issue
> > sorted out first.  Thanks for all the feedback!
>
> Could be the descriptors make the device get picked up by some OS
> class drivers.
>
> Anyway, you the software engineer should work closely with the
> hardware designer to specify the descriptors. I think that's actually
> the largest part of the job, if you want to make something really
> interoperable.
>
(Continue reading)


Gmane