libusb-devel Mailing List for libusb

On Dec 11, 2017, at 1:59 PM, Tom Tatakis <tta...@ap...> wrote:
> 
> Thanks for the info.  Unfortunately, it seems the driver snd-usb-audio tries to talk to the device for about 5 seconds when I plug it in and it enumerates.  I assume that's the driver causing the transfers because I can see it being registered in dmesg when I plug my device in for the first time.  It sets the interface and alt setting to the proper values for the data pipe and tries to transfer data.  It gives up after 5 seconds and sets the alt setting to 0- whether that's because no data is being sent or that's just the way it works I do not know.  

Yes, when a driver releases an interface, it gets set back to setting 0.


> I will let the audio driver handle it when I get my device working- I was just looking for a way to debug easier- If I could create a single isoc transfer and step through my device code, I might be able to figure out what's wrong with my device code.  With all the extra data and interrupts flying around, it just makes it harder....

The device side of isochronous is usually not that hard.  You're just feeding a continuous stream of bytes into a FIFO, and when the USB engine gets an IN token, it sends whatever has accumulated.  The hardest part is writing the descriptors and handling the format negotiation.
— 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

Tom Tatakis via libusb-devel wrote:
>
> Hello- I am working on a project developing a USB Audio device.  It
> implements a microphone and I have it to the point where it enumerates
> as a USB Audio Device on both Windows and Linux.  I am currently
> trying to debug the data pipe on a Linux box (Ubuntu 16).  I find the
> device using the libusb_get_device_list() API and looking for my
> VID/PID.  I then open the device using libusb_open() followed by a
> libusb_reset_device().  Immediately after calling
> libusb_reset_device(), I see isochronous transfers occurring to my
> device- I have not issued any requests for data yet.  So my question
> is- What is performing these transactions and why?

If you are advertising yourself as a USB Audio Class device, then you
should be picking up the standard Linux audio class driver, and it could
be the normal audio subsystem trying to check the volume levels on your
device.  Have you made sure that alternate setting 0 has no endpoints? 
Your isochronous endpoints need to be in alternate settings other than 0.


> I was just trying to write a simple app to pretty much single step
> through an isoch transfer using libusb_interrupt_transfer() so I could
> watch what happens on my device. 

You can't use libusb_interrupt_transfer with an isochronous pipe.  It
will work for interrupt and bulk pipes, but not isochronous. 
Isochronous URBs have a different format.  You have to use
libusb_fill_iso_transfer and libusb_transfer.  There is no synchronous
isochronous (!) API.


> This 'auto isoc data transfer' is getting in my way.  Can it be
> disabled?  Is it part of some audio class driver that is installed
> that I can remove or disable?

Assuming it is a system driver, you'll need to use
libusb_detach_kernel_driver before you can claim your interface.  Why
don't you just let the system audio driver handle it?

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

Hello- I am working on a project developing a USB Audio device.  It
implements a microphone and I have it to the point where it enumerates as a
USB Audio Device on both Windows and Linux.  I am currently trying to debug
the data pipe on a Linux box (Ubuntu 16).  I find the device using the
libusb_get_device_list() API and looking for my VID/PID.  I then open the
device using libusb_open() followed by a libusb_reset_device().
Immediately after calling libusb_reset_device(), I see isochronous
transfers occurring to my device- I have not issued any requests for data
yet.  So my question is- What is performing these transactions and why?

I was just trying to write a simple app to pretty much single step through
an isoch transfer using libusb_interrupt_transfer() so I could watch what
happens on my device.  This 'auto isoc data transfer' is getting in my
way.  Can it be disabled?  Is it part of some audio class driver that is
installed that I can remove or disable?

Any help is appreciated
Thanks in advance.
Tom

Hi,

Actually I  don't need to implement a full compliant ethernet-over-USB
driver like the CDC ones.  A minimal usb+usbg driver pair which just passes
the IP frames back and forth between a usb gadget (Beaglebone black in my
case ) and a linux host should suffice.

Thanks

Nabeel

On Wed, Dec 6, 2017 at 11:28 PM, Tim Roberts <ti...@pr...> wrote:

> Nabeel Syed wrote:
> > thanks for the message.yes its possible to look at standard linux
> > drivers, but thats a long path, lot of code to understand and debug
> > and would require time as i m not an expert in this area.
> > So i was hoping some great open source contributor might have done it
> > already as libusb is around for a while now..
>
> If you are not an expert in this area, then why do you want to dink with
> writing your own driver at all?  What do you think you are going to gain
> over using the well-established and well-tested operating system
> drivers, all of which understand the specs already?
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>

Hello,

I needed the libusb package for using a DJI Guidance System running on a
Ubuntu 16.04 machine. I seem to require the 1.0-9 tar.bz2 file but I did
not find it on the github page, so I decided to use the latest release and
ran ./configure. I had no errors in running ./configure, make and make
install for the libsub package. Eventually, when I was trying to run "make"
for the DJI Guidance package, I got the following errors:

/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_get_device_descriptor'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_init'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_detach_kernel_driver'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_open'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_get_device_list'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_exit'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_get_device'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_get_active_config_descriptor'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_bulk_transfer'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_free_device_list'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_claim_interface'
/home/udoo2/Guidance/Guidance-SDK/so/x64/libDJI_guidance.so: undefined
reference to `libusb_free_config_descriptor'
collect2: error: ld returned 1 exit status
CMakeFiles/dji_guidance_usb.dir/build.make:163: recipe for target
'dji_guidance_usb' failed

Since all the errors seem to refer to libsub, I was wondering if anyone
here could help me out?
Thank you very much for your help!

Best,
Sneha

Nabeel Syed wrote:
> thanks for the message.yes its possible to look at standard linux
> drivers, but thats a long path, lot of code to understand and debug
> and would require time as i m not an expert in this area.
> So i was hoping some great open source contributor might have done it
> already as libusb is around for a while now..

If you are not an expert in this area, then why do you want to dink with
writing your own driver at all?  What do you think you are going to gain
over using the well-established and well-tested operating system
drivers, all of which understand the specs already?

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

>So i was hoping some great open source contributor might have done it already as libusb is around for a while now..

Well I hope you find it!

For CDC ACM I was able to get by just by the USB spec. I use direct
Java usb access (not libusb) on Android to access a USB CDC ACM device.

wbr Kusti

thanks for the message.yes its possible to look at standard linux drivers,
but thats a long path, lot of code to understand and debug and would
require time as i m not an expert in this area.
So i was hoping some great open source contributor might have done it
already as libusb is around for a while now..

On Dec 6, 2017 4:08 PM, "Kustaa Nyholm" <Kus...@pl...> wrote:

> > Is there any example / tutorial code that shows how to talk to cdc_ecm
> device using libusb.????
> Would not the (Linux) standard drivers be the logical place to start from?
>
> Open source - debuggable, reverse engineerable,...
> ... or work from the other end ... look at an open source standard device
> code (most
> chip developers offer device code to developer to get the started with)
>  and
> see what it does/needs to respond to.
>
> just my 2 snt worth.
>
> wbr Kusti
>
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> libusb-devel mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>
>

> Is there any example / tutorial code that shows how to talk to cdc_ecm device using libusb.????
Would not the (Linux) standard drivers be the logical place to start from?

Open source - debuggable, reverse engineerable,...
... or work from the other end ... look at an open source standard device code (most
chip developers offer device code to developer to get the started with)  and
see what it does/needs to respond to.

just my 2 snt worth.

wbr Kusti

Hi Guys,

i am new to using libusb .I have a Beaglebone Black device which is working
in gadget mode and using cdc_ACM,cdc_ECM, RNDS composite gadget...

Now it can talk to standard ubuntu host machine happily .Ubuntu uses
cdc_ether cdc_serial and usbnet drivers to talk to it.

On the ubuntu host side I dont want to use the above mentioned standard
drivers, instead I want to make my own driver using libusb library.
Is there any example / tutorial code that shows how to talk to cdc_ecm
device using libusb.????

I have seen an example using cdc_ACM somewhere online but cannot find
anything  for talking to Ethernet ( ECM ) device.

Any help will be much appreciated Thanks

Nabeel

Hi Tim,
Thank you very much for your answer. 
It brought me a little more insight to the functionality of libusb.
And yes I was changing the DeviceInterfaceGUID.
In the Microsoft docs I came along some of these Class-UIDs, which really
confused me and I thought I'd have to use one of those.

>>From an implementation point of view, an application uses the SetupDi
>>APIs to ask the system "please return me device file names for all devices
that advertise GUID_DEVINTF_GPS_DEVICE".  But once you have a device file
name,  the interface is no >>longer of use.  It is quite possible to have
multiple devices expose the same device interface, and if so, the system
will return them in an indeterminate (but consistent) order.  Is >>it
possible you had more than one device plugged in with the same GUID, and you
were simply getting the wrong one?

I did not have two Devices with the same GUID plugged in. But those GUIDs
get cached somewhere in the registry(local Machine\ System\currentcontrol
set\usb\VID_PID&MI). So there exist several registry entries with the same
GUID, but of interfaces, that are not plugged in currently.

So, if i open the Device by VID:PID and then retrieve the first Interface by
it's GUID, it will probably break.
Because the GUID  I retrieved belongs to an interface that’s not plugged in.

Is this maybe what happens with my setup?




-----Original Message-----
From: Tim Roberts [mailto:ti...@pr...] 
Sent: Freitag, 1. Dezember 2017 18:46
To: lib...@li...
Subject: Re: [libusb] Composite WinUSB interface claim fails

sch...@tw... wrote:
>  
>
> Long story short:
>
> It worked when I adjusted the device GUID.
>

What device GUID?  That term has many overloaded meanings in the Windows
world, and it has no meaning at all in the Linux world.


> For debugging/developing I always incremented the PID(hardware won’t 
> leave my Desk and I don’t have to cope with cached driver 
> installations.. I thought)
>
> But I did not change the WCID device GUID(found in FW USB Stack).
>

Ah, so you mean the DeviceInterfaceGUID in the Microsoft extended
descriptors?


> I’m not sure why it broke in the first place. It’s not a GUID that’s 
> listed in any of the System-defined Device setup Classes, but the 
> default one I got with the Modification of the TI USB Stack.
>

A device interface GUID is not the same as a device setup class GUID, and
Microsoft itself is not consistent about the usage of the terms. The setup
class GUID which appears in INF files (for example, USBDevice which starts
{88BA0E32...}) is basically only used to place your device in the Device
Manager display.

The device interface GUID, on the other hand, is used to associate your
device with a particular set of functions.  It is similar in many respects
to a COM interface GUID.  If you define GUID_DEVINTF_GPS_DEVICE (which I
just made up), and you define the requests and transfers that your device
will support, then you are saying that ANY device that exposes
GUID_DEVINTF_GPS_DEVICE will support those requests and transfers.

>From an implementation point of view, an application uses the SetupDi
APIs to ask the system "please return me device file names for all devices
that advertise GUID_DEVINTF_GPS_DEVICE".  But once you have a device file
name,  the interface is no longer of use.  It is quite possible to have
multiple devices expose the same device interface, and if so, the system
will return them in an indeterminate (but consistent) order.  Is it possible
you had more than one device plugged in with the same GUID, and you were
simply getting the wrong one?


> So. Maybe you could please help me and point me to something where I 
> find out about these GUIDs. Or tell me if they are:
>
> -device-unique?
>
> -class-unique?
>
> -just arbitrary random numbers I can make of?
>

You generate your Device interface GUIDs yourself.  They are not, strictly
speaking, random numbers; they have a specific structure in order to
guarantee universal uniqueness.  Use the "uuidgen" or "guidgen"
tools to generate them.

The Class GUIDs in the INF file a bit different.  There are a set of
standard ones, but you can certainly declare your own, and you'll get your
own subheading in Device Manager.


> Why did it break when I recycled the GUID on multiple different 
> VID:PID combinations?
>

My best guess is that you were getting some other device.  The device
interface GUID has no functional purpose except to facilitate finding the
device.

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


----------------------------------------------------------------------------
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
libusb-devel mailing list
lib...@li...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

sch...@tw... wrote:
>  
>
> Long story short:
>
> It worked when I adjusted the device GUID.
>

What device GUID?  That term has many overloaded meanings in the Windows
world, and it has no meaning at all in the Linux world.


> For debugging/developing I always incremented the PID(hardware won’t
> leave my Desk and I don’t have to cope with cached driver
> installations.. I thought)
>
> But I did not change the WCID device GUID(found in FW USB Stack).
>

Ah, so you mean the DeviceInterfaceGUID in the Microsoft extended
descriptors?


> I’m not sure why it broke in the first place. It’s not a GUID that’s
> listed in any of the System-defined Device setup Classes, but the
> default one I got with the Modification of the TI USB Stack.
>

A device interface GUID is not the same as a device setup class GUID,
and Microsoft itself is not consistent about the usage of the terms. 
The setup class GUID which appears in INF files (for example, USBDevice
which starts {88BA0E32...}) is basically only used to place your device
in the Device Manager display.

The device interface GUID, on the other hand, is used to associate your
device with a particular set of functions.  It is similar in many
respects to a COM interface GUID.  If you define GUID_DEVINTF_GPS_DEVICE
(which I just made up), and you define the requests and transfers that
your device will support, then you are saying that ANY device that
exposes GUID_DEVINTF_GPS_DEVICE will support those requests and transfers.

>From an implementation point of view, an application uses the SetupDi
APIs to ask the system "please return me device file names for all
devices that advertise GUID_DEVINTF_GPS_DEVICE".  But once you have a
device file name,  the interface is no longer of use.  It is quite
possible to have multiple devices expose the same device interface, and
if so, the system will return them in an indeterminate (but consistent)
order.  Is it possible you had more than one device plugged in with the
same GUID, and you were simply getting the wrong one?


> So. Maybe you could please help me and point me to something where I
> find out about these GUIDs. Or tell me if they are:
>
> -device-unique?
>
> -class-unique?
>
> -just arbitrary random numbers I can make of?
>

You generate your Device interface GUIDs yourself.  They are not,
strictly speaking, random numbers; they have a specific structure in
order to guarantee universal uniqueness.  Use the "uuidgen" or "guidgen"
tools to generate them.

The Class GUIDs in the INF file a bit different.  There are a set of
standard ones, but you can certainly declare your own, and you'll get
your own subheading in Device Manager.


> Why did it break when I recycled the GUID on multiple different
> VID:PID combinations?
>

My best guess is that you were getting some other device.  The device
interface GUID has no functional purpose except to facilitate finding
the device.

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

Hello there again,

 

Long story short:

It worked when I adjusted the device GUID.

For debugging/developing I always incremented the PID(hardware won't leave
my Desk and I don't have to cope with cached driver installations.. I
thought)

But I did not change the WCID device GUID(found in FW USB Stack).

I'm not sure why it broke in the first place. It's not a GUID that's listed
in any of the System-defined Device setup Classes, but the default one I got
with the Modification of the TI USB Stack.

 

So. Maybe you could please help me and point me to something where I find
out about these GUIDs. Or tell me if they are:

-device-unique?

-class-unique?

-just arbitrary random numbers I can make of?

 

Why did it break when I recycled the GUID on multiple different VID:PID
combinations?

 

On 

https://github.com/libusb/libusb/wiki/Windows

it's only said that the device must have a GUID, but not whether I can
recycle it.

 

Thanks in advance

 

 

From: sch...@tw... [mailto:sch...@tw...] 
Sent: Freitag, 1. Dezember 2017 12:15
To: 'lib...@li...'
<lib...@li...>
Subject: Composite WinUSB interface claim fails

 

Hello There,

 

I'm looking for some help in developing a libusb-application.

 

I'm developing the Hardware as well as the software and require some more
understanding of the libusb.

I'm developing on WIN10.

 

My current situation is following:

I'm using a composite Device having winUSB attached to the first two
interfaces, using WCID. (Next two interfaces are CDC Devices)

They get reported as IF0/1 by USB tree Viewer.

So I have to open interface 0/1 with libusb?

The first attempt to open this device fails, as expected, because to being
the composite parent,

The second one succeeds.

 

Claiming Interface 1 works(my application and xusb report no error on this)

Claiming Interface 0 returns a -12(libusb_not_supported) error, xusb reports
6 Ifs being present(one more than expected)

And fails on all except Interface 1.

 

The Docs say that claiming is a purely logical operation, which means my
firmware does not have to do anything with it.

So I assume this is a Windows/libusb error I have to deal with.

 

I was using libusb 1.0.20 when I somewhen found out that the composite
device support is much better on 1.0.21.

Now I'm using the github Version, compiled with MSVC2015(was just compiling
fine - awesome)

 

Could you please give me advice on how I can get fixed this?

 

My current code is attached.

 

             bool deviceFound = false;

             int i = -1;

             

             while ((deviceFound == false) && ( (++i) < numDevices))

             {

                    dev = usbDevices[i];

                    libusb_get_device_descriptor(dev, &desc);

 

                    

                    if ((desc.idVendor == TIVA_USB_VID) & (desc.idProduct ==
TIVA_USB_PID)) {

                           //Found some candidate;

                           int tst = libusb_open(dev, &m_pUSB);
//crashes, when being composite parent

 

                           if ( tst > -1) 

                           {

                                  if (m_pUSB != NULL )

                                  {

                                        deviceFound = true;

                                        this->setIdentifier(QString("XCD
Bulk Pipe"));

                                  }

                           }

 

                    }

             }//End of while loop

 

        if(usbDevices)

        {

            libusb_free_device_list(usbDevices, 1);

        }

    }

 

       //Make the device available to this applicatrion;

    if(!retValue.containsError())

    {

             int test = 0; //set default Configuration value;

             //detaching kernel drivers is mostly needed when interfaceing
to HID Devices(especially on MAC OS and Linux

           m_autoDetach  = (libusb_set_auto_detach_kernel_driver(m_pUSB, 1)
== LIBUSB_SUCCESS) ;       //Try setting Kernel detach;

 

             int val;

             status = libusb_get_configuration(m_pUSB, &val);

             status = libusb_set_configuration(m_pUSB, val);

 

             libusb_config_descriptor *config;

             status =
libusb_get_config_descriptor(libusb_get_device(m_pUSB), 0, &config);

             status = libusb_claim_interface(m_pUSB, TIVA_INTERFACE_NUMBER);
//               ->            FAILS ON IF0, SUCCEEDS on IF1

             if (status < 0) 

        {

                    retValue += ito::RetVal(ito::retError, status,
libusb_error_name(status));

             }

    }

Hello There,

 

I'm looking for some help in developing a libusb-application.

 

I'm developing the Hardware as well as the software and require some more
understanding of the libusb.

I'm developing on WIN10.

 

My current situation is following:

I'm using a composite Device having winUSB attached to the first two
interfaces, using WCID. (Next two interfaces are CDC Devices)

They get reported as IF0/1 by USB tree Viewer.

So I have to open interface 0/1 with libusb?

The first attempt to open this device fails, as expected, because to being
the composite parent,

The second one succeeds.

 

Claiming Interface 1 works(my application and xusb report no error on this)

Claiming Interface 0 returns a -12(libusb_not_supported) error, xusb reports
6 Ifs being present(one more than expected)

And fails on all except Interface 1.

 

The Docs say that claiming is a purely logical operation, which means my
firmware does not have to do anything with it.

So I assume this is a Windows/libusb error I have to deal with.

 

I was using libusb 1.0.20 when I somewhen found out that the composite
device support is much better on 1.0.21.

Now I'm using the github Version, compiled with MSVC2015(was just compiling
fine - awesome)

 

Could you please give me advice on how I can get fixed this?

 

My current code is attached.

 

             bool deviceFound = false;

             int i = -1;

             

             while ((deviceFound == false) && ( (++i) < numDevices))

             {

                    dev = usbDevices[i];

                    libusb_get_device_descriptor(dev, &desc);

 

                    

                    if ((desc.idVendor == TIVA_USB_VID) & (desc.idProduct ==
TIVA_USB_PID)) {

                           //Found some candidate;

                           int tst = libusb_open(dev, &m_pUSB);
//crashes, when being composite parent

 

                           if ( tst > -1) 

                           {

                                  if (m_pUSB != NULL )

                                  {

                                        deviceFound = true;

                                        this->setIdentifier(QString("XCD
Bulk Pipe"));

                                  }

                           }

 

                    }

             }//End of while loop

 

        if(usbDevices)

        {

            libusb_free_device_list(usbDevices, 1);

        }

    }

 

       //Make the device available to this applicatrion;

    if(!retValue.containsError())

    {

             int test = 0; //set default Configuration value;

             //detaching kernel drivers is mostly needed when interfaceing
to HID Devices(especially on MAC OS and Linux

           m_autoDetach  = (libusb_set_auto_detach_kernel_driver(m_pUSB, 1)
== LIBUSB_SUCCESS) ;       //Try setting Kernel detach;

 

             int val;

             status = libusb_get_configuration(m_pUSB, &val);

             status = libusb_set_configuration(m_pUSB, val);

 

             libusb_config_descriptor *config;

             status =
libusb_get_config_descriptor(libusb_get_device(m_pUSB), 0, &config);

             status = libusb_claim_interface(m_pUSB, TIVA_INTERFACE_NUMBER);
//               ->            FAILS ON IF0, SUCCEEDS on IF1

             if (status < 0) 

        {

                    retValue += ito::RetVal(ito::retError, status,
libusb_error_name(status));

             }

    }