I am trying to (programatically in Java, though running external scripts is a possibility) get the USB idProduct, idVendor and ideally the string descriptors for the manufacturer and product for a USB device.
The device has (and it is all I am provided with in the beginning) a /dev/tty.usbmodem entry, and I need some way to reliably map that back to the USB information, but I can't find anything that relates one to the other (or rather I don't know where to look).
The device in question has the /dev entry of:
crw-rw-rw- 1 root wheel 10, 2 18 Jul 15:08 /dev/tty.usbmodem9f31
system_profiler gives me the following USB information for the device:
<dict>
<key>_name</key>
<string>Stk500v2</string>
<key>a_product_id</key>
<string>0xa662</string>
<key>b_vendor_id</key>
<string>0x0403 (Future Technology Devices International Limited)</string>
<key>c_bcd_device</key>
<string> 1.80</string>
<key>e_device_speed</key>
<string>full_speed</string>
<key>f_manufacturer</key>
<string>www.cpustick.com</string>
<key>g_location_id</key>
<string>0x9f300000</string>
<key>h_bus_power</key>
<string>500</string>
<key>j_bus_power_used</key>
<string>500</string>
</dict>
I can see the prefix of 0x9f3 for the g_location_id matching the start of the dev entry's suffix of 9f31, but I don't know a) how reliable that would be, and b) what the "1" would represent at the end, and how that would be affected by having multiple of the same device on the same bus, and how you would differentiate between them.
I have other devices I need to do this with as well, and they don't all follow the same naming rules. One of them uses the USB serial number field for the suffix. Other potential ones (that I don't have control over at all) could do it differently again I guess.
So basically I need some way of mapping the textual device name /dev/tty.whatever to a physical USB device entry that I can then pull the data I need from. On Linux I do it by traversing the /sys tree from /sys/class/tty through to /sys/devices/pci...blahblah/usb[x]/wherever but I can find no similar facility on OS X.
You can use IOKit to get the USB vendor ID and product ID of a serial port on Mac OS X.
Also, there is a library called libserialport that you could use:
http://sigrok.org/wiki/Libserialport
Related
I'd like to find a way to figure out physical slot of a PCI-E device from the bus address. I would like to use to modify a driver/kernel module, so it would enumerate the devices (with the same ID) and disambiguate the device files according to physical slot. Like /dev/device_physslot . The driver will run on Ubuntu 18
lspci is capable to show physical slot number in the verbose presentation
However, as I found out, it accomplishes it over sysfs, which cannot be accessed from kernel module.
So I need to do it somehow with system calls.
Or perhaps it is possible to figure out, where sysfs gets /sys/bus/pci/slots/slot_num/address property?
How does an OS maps USB device with its device driver? I understand that in the interface descriptor of client USB firmware if no class type has been selected for the device then developer has to provide its own device driver.
I am keen to know how OS maps the pluggged USB device with its device driver? Does descriptors in the USB client firmware contains the file name of the custom device driver? Please let me know.
As a hobby, I have done quite a bit of work with the USB hardware, and had these same questions when I first started.
An OS can map a USB device any way it wants. However, to be more precise toward your question, a USB device will, and must return a class and interface code. Granted, that class code can be 0xFF for user-defined, where the device now must require a unique driver.
In my opinion, this is where the USB shines. All USB devices that return a valid class code specified within the USB specification, will and must follow a specific sequence of events and will "work right out of the box" as indicated. However, this doesn't mean that it cannot have extra capabilities.
For example. A pointing device, such as a mouse, will probably always follow the boot protocol when first plugged in. This is the protocol used and specified in the USB specification so that any OS that follows this protocol can use this pointing device. This protocol specifies a simple three (or more) byte packet for pointer input.
Byte Description
0 Button(s)
1 X Displacement
2 Y Displacement
3 (Device Specific) (optional)
Any pointing device that follows the USB specification most likely has this protocol and will use this protocol until told otherwise. This is so any USB capable OS can use the pointing device.
Every USB device also has a vendor, device, and protocol definition. Once the OS has found this device, it can search through its drivers for a driver that can support this device. That driver, once loaded, can then tell the device to now use a different protocol. i.e.: Return a different Input Report.
Here is an example. Let's say that you have a fancy gaming mouse with three directions of displacement (X, Y and Z), and six buttons. As the OS is booting, it probably has no idea how to use that mouse. Therefore, the manufacturer creates the mouse to use the boot protocol shown above until the driver can be loaded. Once the driver is loaded, which knows how to use the three direction displacements and all six buttons, it can tell the mouse, through a Control packet, maybe the SET INTERFACE command as well, to now start sending a different report, now using the full capabilities of the mouse.
So, as along as the device is USB specification accurate, and has a class code not of user defined (0xFF), the device will be recognized, even if it is a minimal use and/or is to show a statement that a driver is needed.
As for giving a file name of a custom device driver, this is all up to the device manufacturer. However, usually this is not that case. Usually, the OS will retrieve the DEVICE DESCRIPTOR which contains the manufacturer, device, protocol, and other fields. It will then match any driver to those fields. If it does not find a compatible driver, it will ask for one.
For example, one of the pointing devices I used with my research has the following few bytes of the 18-byte Device Descriptor:
Offset Field Value
0 Length 0x12
1 Type 0x01
2 Release Num 0x0110
4 Device Class 0x00
5 Sub Class 0x00
6 Protocol 0x00
7 MaxPacketSz 0x08
8 VendorID 0x04FC
10 Product ID 0x0003
...
Notice that it specifies the Vendor and the Product. Using these two values, a compatible driver can be found.
Now, notice that the class code is zero. This is not an error and is a perfectly valid class code, and simply means that the interface descriptor is to be used instead.
So, hopefully with this information, and specifically, the Manufacturer and Product codes within the DEVICE DESCRIPTOR, you can now see how an OS can find the correct driver for any device.
There are various ways to retrieve the Windows "Device Name" of a HID device, GetRawInputDeviceInfo with RIDI_DEVICENAME being one way to do it.
Given the example name:
\?\HID#VID_FEED&PID_DEAD#6&3559c8ea&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd}
I'm wondering if there is any documentation whatsoever on what is what in this string?
\?\HID#VID_AAAA&PID_BBBB#C&DDDDDD&E&FFFF#{GUID}
So the obvious ones are A(VID), B(PID) and the GUID on the end. What I'm wondering is what EXACTLY are C, D, E and F?
It seems that C and D are unique even if you plug in two of the exact same HID devices which is great for my problem, but I'd feel more comfortable if I could know exactly how this is determined on a per OS basis, or at least that it follows some known format.
I have been googling like a madman trying to figure this out, am I missing something obvious?
Thanks in advance
According to a similar MSDN post, the value represents a unique device instance ID:
the device instance ID is unique and constant for the physical
location the device is plugged into, but it is also opaque and should
not be parsed. that means it can be used for string comparison, but
not for interpretation.
It is actually device interface instance id (symbolic link name). And yes, its unique and persists across system restart. Some details also here.
You can use CM_Get_Device_Interface_Property or SetupDiGetDeviceInterfaceProperty on interface instance id with DEVPKEY_Device_InstanceId to get device instance id (one device can have multiple interfaces).
In your example - you have a HID device. Its device id format is described here.
Info on general USB devices id format is here.
After you have device instance id you can use CM_Get_DevNode_Property or SetupDiGetDeviceProperty with DEVPKEY_NAME to get localized friendly name of a device (which is shown in Device Manager).
To sum up:
\\?\HID#VID_203A&PID_FFFC&MI_01#7&2de99099&0&0000#{378de44c-56ef-11d1-bc8c-00a0c91405dd} - is device interface id (also referred as "device interface path" or "device name" in docs). This is path in virtual device file system.
{378de44c-56ef-11d1-bc8c-00a0c91405dd} - device interface class guid (GUID_DEVINTERFACE_MOUSE in this case. It determines which IOCTLs can be called on this device. IOCTL_MOUSE_QUERY_ATTRIBUTES in this case)
HID\VID_203A&PID_FFFC&MI_01\7&2de99099&0&0000 - is device instance id
NOTE: exact device interface id format is not documented, each device interface can generate file name it want. I don't recommend you to parse it - it could be changed in later Windows version, better aquire device instance id - it is documents at least.
How to uniquely identify computer (mainboard) using C#(.Net/Mono, local application)?
Edition. We can identify mainboard in .Net using something like this (see Get Unique System Identifiers in C#):
using System.Management;
...
ManagementObjectSearcher searcher = new ManagementObjectSearcher("select * from Win32_MotherboardDevice");
...
But unfortunately Mono does not support System.Management. How to do it under Mono for Linux? - I don't know :(
Write a function that takes a few unique hardware parameters as input and generates a hash out of them.
For example, Windows activation looks at the following hardware characteristics:
Display Adapter
SCSI Adapter
IDE Adapter (effectively the motherboard)
Network Adapter (NIC) and its MAC Address
RAM Amount Range (i.e., 0-64mb, 64-128mb, etc.)
Processor Type
Processor Serial Number
Hard Drive Device
Hard Drive Volume Serial Number (VSN)
CD-ROM / CD-RW / DVD-ROM
You can pick up a few of them to generate your unique computer identifier.
Please see: Get Unique System Identifiers in C#
You realistically have MotherboardID, CPUID, Disk Serial and MAC address, from experience none of them are 100%.
Our stats show
Disk serial Is missing 0.1 %
MAC Is missing 1.3 %
Motherboard ID Is missing 30 %
CPUID Is missing 99 %
0.04% of machines tested yielded no information, we couldn't even read the computer name. It maybe that these were some kind of virtual PC, HyperV or VMWare instance, or maybe just very locked down? In any case your design has to be able to cope with these cases.
Disk serial is the most reliable, but easy to change, mac can be changed and depending on the filtering applied when reading it can change if device drivers are added (hyperv, wireshark etc).
Motherboard and CPUID sometimes return values that are invalid "NONE", "AAAA..", "XXXX..." etc.
You should also note that these functions can be very slow to call (they may take a few seconds even on a fast PC), so it may be worth kicking them off on a background thread as early as possible, you ideally don't want to be blocking on them.
Try this:
http://carso-owen.blogspot.com/2007/02/how-to-get-my-motherboard-serial-number.html
Personally though, I'd go with hard drive serial number. If a mainboard dies and is replaced, that PC isn't valid any more. If the HDD drive is replaced, it doesn't matter too much because the software was on it.
Of course, on the other hand, if the HDD is just moved elsewhere, the information goes with it, so you might want to look at a combination of serial numbers, depending what you want it for.
How about the MAC address of the network card?
Is there a way to assign one HID device to a program and then another identical HID device to another program without each of them grabbing randomly the first HID device they enumerate? I'd need some kind of unique identifier. Is there such thing? On windows xp/vista/7.
The port is your default enumeration value. Configure your code to allow explicit specification of the port.
Depending on a uuid of a device is probably not going to give you the results you expect in the long run.