Recent Posts

1

USB / Re: USB HID Driver connecting to which interface number

« Last post by grantb5 on November 27, 2024, 01:34:16 pm »

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.

Just curious how one "filters on VID/PID/Interface#"?  Like the OP I am adding a 2nd interface to something that has traditionally only had 1 interface. In the old case there was no &MI_## found in the GUID/path string (result found in detailData->DevicePath). Now that the 2nd interface has been added, the string contains &MI_00 or &MI_01 depending on the interface been looked at. Are you just scanning the string for absence/0/1/etc, or is there a more clever way to tell?

2

USB / The PORTS forum is closed to new activity

« Last post by Jan Axelson on August 14, 2023, 12:39:29 pm »

This forum is closed to new activity. The posts are available to browse, but posting has been disabled. BIG THANKS to all who have participated and shared your knowledge over the past 13 years. - Jan

3

USB / Re: control trasfers on xinput

« Last post by Jan Axelson on August 12, 2023, 02:57:46 pm »

Control transfers aren't specific to HID, but the class-specific HID control transfers are specific to HID. That said, I don't know the answer to your question.

4

USB / Re: control trasfers on xinput

« Last post by ulao on August 12, 2023, 11:05:35 am »

There is no doubt that xinput and hid are not the same, but control transfers are not specific to HID are they? the xinput uses the set get in the same way
XInputSetState function (xinput.h)
XInputGetState function (xinput.h)
I even use it in the same functions in my firmware. but I'm just not finding a definitive answer if the control transfers from application can reach xinput.

5

USB / Re: control trasfers on xinput

« Last post by Jan Axelson on August 11, 2023, 09:48:27 pm »

This suggests it's not possible:


https://stackoverflow.com/questions/52088857/i-need-some-help-to-understand-usb-game-controllers-hid-devices

6

USB / control trasfers on xinput

« Last post by ulao on August 11, 2023, 06:20:22 pm »

I was wondering if anyone here knows if the xinput driver supports control transfers. This may sound vague but need to see if anyone out there can help before I go in to too much details.

history: I made a popular HID usb adapter that uses the control set / get transfers. I ended up going to a new chip and ported all my code over and added support for xinput ( vie a hard jumper).  I had to make a new descriptor for this and I'm not sure how to set up, or if it is even possible to use control transfers. I could open up another pipe as a pass-tru to the control transfer functions but I'd hope I could just  let the application support the device in the same way it did the hid. I'm not sure that will work.

by control transfers I referring specifically to HID_REQ_GetReport and HID_REQ_SetReport and how the descriptor will define what each set and get does.


for HI I have something like the below where "get pad data" is a function I can access from my application.

   0x09,0x01, // USAGE (Vendor Usage 1)
   0xa1, 0x01,                    // COLLECTION (Application)
   0x15, 0x00,                    //   LOGICAL_MINIMUM (0)
   0x26, 0xff, 0x00,              //   LOGICAL_MAXIMUM (255)
   0x75, 0x08,                    //   REPORT_SIZE (
 
 
       //get pad data
      0x85, 0x10,                    //   REPORT_ID (16)
      0x95, 0x0D,                    //   REPORT_COUNT (13) one less then rid
      0x09, 0x00,                    //   USAGE (Undefined)
      0xb2, 0x02, 0x01,              //   FEATURE (Data,Var,Abs,Buf)

can I do that in the ximput descriptor somehow so that the same Rid works with it?


more detail provide if requested of course.

7

USB / Re: USB 2.0 cameras in motherboard vs in hub

« Last post by Renate on June 14, 2023, 09:01:51 am »

This is not related to your current problem but it might be helpful to someone else.

Host controllers have a finite number of total endpoints that they can manage, I've seen 96.
If you go crazy plugging stuff in with lots of endpoints you might run into this.
A new device will displace an old device.

I made a test device once with 32 endpoints.
Note that the underlying hardware doesn't need to be that big.
You just need to make your descriptors with interfaces and endpoints.

8

USB / Re: USB 2.0 cameras in motherboard vs in hub

« Last post by zubarka on May 30, 2023, 08:27:39 am »

Thank you! From what I understand the chipset guarantees full usb 2.0-bandwidth for all ports which explain why multiple cameras work. It is a bit weird though that the OS still only see it as one usb controller.

A follow-up question: I can see (using e.g. usbtop on linux) that my usb 2.0 camera uses a maximum of 10Mb/s when streaming mjpeg-compressed fullHD. Is it not reasonable to think that the controller should be able to handle at least two such streams within its 40Mb/s bandwidth? Yet I always get out-of-bandwidth errors whenever I try to start a second camera.

9

USB / Re: USB 2.0 cameras in motherboard vs in hub

« Last post by Jan Axelson on May 29, 2023, 09:40:47 pm »

This might help explain it.

https://electronics.stackexchange.com/questions/403090/how-to-determine-bandwidth-available-at-usb-ports

10

USB / USB 2.0 cameras in motherboard vs in hub

« Last post by zubarka on May 29, 2023, 07:28:13 am »

Hi everyone,

I have a specific problem with USB that I hope someone here can help me with.

On my computer I have one USB 3.0 and one USB 2.0 controller. We are using multiple USB 2.0 cameras for a computer vision application, which
work fine since several compressed streams fit in the available bandwidth of 480Mbit/s. Using the usb ports in the motherboard I have successfully connected up to seven cameras without issue, which I have verified are connected to the same USB 2.0 controller.

However, when I plug in a usb hub (2.0 or 3.0, powered/unpowered, have tested all), I can only get one camera to work at the same time. As soon
as I start the second camera it complains about insufficient bandwidth. To me this is very weird since I know from above test that the bandwidth should not be a problem.

I have tested this on both linux (6.3.4) and Windows 10 with identical results.

We know that we can solve this problem by going to USB 3.0 cameras, but they are unfortunately much more expensive and not as commonly available. We also have external pci-cards with separate USB 2.0 controllers which work, but we are still limited to one camera/controller in that case (and we want to use MANY cameras).

Have anybody else seen this problem or now what the reason could be?