Get information about the USB port used by a device

[Vedrillan]

I could not find a way to know on which USB port is a plugged in HID device.

When looking at dmesg logs on linux, the message will be as follow when I plug in a device:

hid-generic 0003:2C97:0015.0039: hiddev9,hidraw10: USB HID v1.11 Device [Something] on usb-0000:00:1d.0-1.2/input0

The usb-0000:00:1d.0-1.2 part seems to identify the exact USB port used by the device, would it be possible to get this kind of information from hidapi?

[todbot]

That's the path attribute of list of hid_device_info entries returned by hid_enumerate().

[todbot]

Oh apologies, that's not the case in the Linux hidraw implementation, where path just points to the hidraw device path.
On Linux, you can do udevadm info -q path -n /dev/hidraw0 to get the USB hierarchy path:

$ udevadm info -q path -n /dev/hidraw0 
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0/0003:27B8:01ED.0019/hidraw/hidraw0

[Vedrillan]

Ok so indeed with hidraw it is possible to get additional info, I will search how to do that from the code directly though, with libudev I suppose.

However with the libusb implementation the path provides the bus and the device address but it looks like several physical ports can share the same bus and the address is an auto-incremented value, so it is not possible to identify the physical port from the path.

In my case it is not really a "hid" thing but more of a udev related information, still, in my opinion it would be nice to have something cross implementation that provides the identity of the physical usb port on which the device is plugged in.

In the meantime I will switch to the hidraw implementation and check udev to get the additional info, feel free to close this issue if that is not something you want in the hidapi.

[Youw]

We have plans to change the PATH format for libusb backend: #117
Try if that would contains what you want.

[Vedrillan]

What I went for is to use udev lib to get the sysfs path of the device from /dev/hidraw10 and then find the parent device with subsystem usb, which gives for instance /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1:1.0. From the doc it is supposed to be a unique key to the device, which is what I was looking for.

I do not think this is something that could be added to the path in the case of hidraw backend, however maybe there could be like a new "physical_id" property to the device.

[Youw]

the path itself is designed to be a unique "id" of the device, on all platforms

[Youw]

what exactly are you looking for?

[Vedrillan]

What I meant is that the hidapi device paths are not related to the physical device link (or maybe partially). Just from the hidapi device path, it is not possible to tell if a device has been disconnected and plugged back in the same usb port.

So what I was looking for is a "path" that does not change when reconnecting the same device to the same usb port.

[Youw]

they aren't, and by design they might not even be the same for the same device plugged twice into the same port

HID device is an abstraction, and any attempt to match it over the real physical device, might be just a workaround that happens to work in a particular environment, or with a specific device

on the other hand - HID device abstraction has some well defined properties, that you could use that achieve what you want: VID+PID+Serial number
Basically, do the other way around. For instance:

• have some kind of hook to monitor (USB) device connection/disconnection (likely a platform specific one);
• have a mechanism to match that a connected physical (USB) device is the one that you're looking for (connected to the same USB port);
• check its USB device VID+PID+Serial number - has to be available for most USB devices;
• when you find your device (by VID+PID or by VID+PID+SN) you can easily open a corresponding HID device

[Vedrillan]

And I pretty much agree, that is why in a previous comment I said this:

In my case it is not really a "hid" thing but more of a udev related information, still, in my opinion it would be nice to have something cross implementation that provides the identity of the physical usb port on which the device is plugged in.

The issue with your suggestion is that hidapi is supposed to abstract usb as you said, so having to use and learn more concrete usb implementation defeats a bit the purpose of the abstraction. If I am here looking at hidapi it is because I have already been "failed" by several layers of library and abstraction (I am not even coding in C).

If you think that hidapi should not provide information to identify the physical link used by a device, I suppose it is a legitimate choice (I do not even know the HID specs) but all I can say for sure is that if the hidapi device object had some kind of property that was reflecting the physical usb port used, it would have saved me several hours of research and learning of concrete implementations (hidraw, udev, sysfs, libusb).

[Youw]

Unfortunately such property is not possible to implement, not for a general case.

First of all, because HID specification (at least the part implemented by hidapi) is agnostic to the USB device, as a device implementation. E.g. "physical USB port" property makes no sense for a Bluetooth HID device.

Secondly - hidapi is a cross-platform library, and when libusb backend might easily give a physical USB port, for others (Windows/macOS/hidraw) - it might not be as easy, or not possible at all (without deep platform-specific hacks).

---

If you know exactly what you need, and know exactly your platform (e.g. Linux + hidapi/libusb), I can only suggest to have your own fork with the property you need implemented.

[Vedrillan]

When using the hidraw backend on linux, I only need a few extra steps to get a usb port identifier with libudev, it will do for now.

Thanks for all the information.