Author Topic: USB HID Driver connecting to which interface number  (Read 14539 times)

MB_Inv

  • Member
  • ***
  • Posts: 8
USB HID Driver connecting to which interface number
« on: January 17, 2022, 07:10:44 am »
Hi,

we're using our product as a USB composite device with 2x CustomHID interfaces.

On the host side, we're using the following USB HID Driver:
https://github.com/libusb/hidapi

For connecting to one of the interfaces, this driver offers to functions:
- one which takes VID, PID and (optional) serial number
- one which takes only the path

When using the first, automatically the interface with the highest interface nr found is used.

Now, my question is as follows:
According to your experience, do host USB HID drivers usually use the highest interface nr found (in our case, interface 1 instead of interface 0) or does that differ?
Or, differently put, when our customers use some USB HID driver and uses some function taking only VID and PID to connect, can we safely assume that all will connect to interface 1?

Kind regards,

Markus

Renate

  • Frequent Contributor
  • ****
  • Posts: 97
Re: USB HID Driver connecting to which interface number
« Reply #1 on: January 18, 2022, 05:55:36 am »
I would guess (without any evidence) that they would use the lowest interface number.

It seems to me that if the first function doesn't allow you to specify interface number then you should either:
  • Use the second function that takes a path and write your own helper that generates a path from VID/PID/Interface#
  • Only use one HID interface and multiple HID reports. This makes sense unless the two interfaces are separately used by two applications.
When I do my own stuff finding/connecting to a USB HID I filter on VID/PID/Interface#.

Unrelated trivia: The AMD Aura USB HID (silly LED lighting) has non consecutive interface numbers which is illegal and breaks some USB libs.

MB_Inv

  • Member
  • ***
  • Posts: 8
Re: USB HID Driver connecting to which interface number
« Reply #2 on: January 19, 2022, 04:43:27 am »
Hi Renate,

thanks for your thoughts!

We are indeed using the same approach as you in our own SW (get the path of the desired interface nr and then connect using the path).
However, we don't know what our customers are using.

Until now, our device had only 1x CustomHID interface. Customers might have connected to it using a function which doesn't take the interface nr as argument, because there is only one.
However, now we changed to a composite device and added another interface and want to provide a SW to the customer dealing with this second interface. So, we're trying to find a way to prevent the customer from using the same interface on accident (which would screw up the communication on this interface).

So I asked myself if we could safely assume that normally different USB HID host drivers select the same interface when the interface nr is not specified...

Kind regards,

Markus

Renate

  • Frequent Contributor
  • ****
  • Posts: 97
Re: USB HID Driver connecting to which interface number
« Reply #3 on: January 19, 2022, 06:09:09 am »
You could make "your" interface use a private class (0xff) and not HID.

MB_Inv

  • Member
  • ***
  • Posts: 8
Re: USB HID Driver connecting to which interface number
« Reply #4 on: January 20, 2022, 02:27:42 am »
Would I then be still able to use the hidapi driver on the host side for the "private" interface or would I need to write an own driver?

Kind regards,

Markus

Jan Axelson

  • Administrator
  • Frequent Contributor
  • *****
  • Posts: 3033
    • Lakeview Research
Re: USB HID Driver connecting to which interface number
« Reply #5 on: January 20, 2022, 10:06:36 am »
I wouldn't assume that host drivers would do something that isn't specified as required.

If it's not HID class, it will need a different host driver.

Renate

  • Frequent Contributor
  • ****
  • Posts: 97
Re: USB HID Driver connecting to which interface number
« Reply #6 on: January 20, 2022, 12:30:21 pm »
But you could use a WinUsb driver (like everybody seems to do for everything these days).