Hello,
Has any headway been made regarding JInput and its ability to provide handling for multiple Controllers of the exact same type? For example, when you receive back an array of Controllers after calling getControllers(), would it be possible to obtain the USB Bus/Port Number (or any other info) that the controller is attached to?the Controller class provides several methods to retrieve type, port and other properties… 
Right, but whenever I run the ControllerTextTest main class to get the list of controllers, the USB controllers that I’m interested in return the Port Type and Port Number as “Unknown” and “0”, respectively.
did you check the physical device that handles the usb port ? if it is not well supplied then “unknown device” would arise.
I do use the Controller class to provide support for usb gamepads and joysticks, that works well for me.
Cool, thanks for the info. But how can I tell if my physical device is “well supplied?”
if you use an DC-power unsupplied hub device between the pad and your pc, try plugging directly into the pc usb plug ! 
I think I’m already plugging directly into the USB ports actually, and no such luck using the getPortNumber() method. My ultimate goal is to predetermine the ordering of the returned Controller array based on USB push-to-talk (PTT) headset devices I have plugged in. I’m using a Java program called jUSB to obtain the Vendor ID and Product ID of headsets I have plugged in. I can also determine the driver “instance” of the attached headsets. For example, everytime I attach a USB headset into a USB port on my computer for the first time, an entry gets placed into the HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Enum \ USB folder of my registry. The Driver field for the entry is:
{36FC9E60-C465-11CF-8056-444553540000} \ xxxx
, where the value xxxx seems to get incremented each time a headset is intially plugged into a USB port that has never had a headset before. One pseudo-pattern I’m seeing right now is that if one USB port has instance (x) of the headset driver, and the second port has instance (x+1), then the lower-numbered instance (i.e. the first USB port) will have its PTT button status correspond to the first Controller in the Controller array.
I say it’s a pseudo-pattern because it’s consistent about 90% of the time for devices with identical vendor and product IDs. However, I also have to account for a monaural headset that has the same vendor ID but different product ID. If I have one of these monaural headsets plugged in and another of a different kind plugged in, the monaural headset’s PTT button status ALWAYS seems to get placed first into the Controller array.
Am I just spinning my wheels with this approach? I was hoping there would be an easier way. Thanks for the help.
actually JInput is intended for gamepad support not headset, you better try some kind of sound system API.
I fully intend to use the headset as a game controller, albeit single-button for the PTT. In fact, it’s recognized as an “installed game controller” in the Control Panel. I’m handling the audio portion with Java’s sound package’s Mixer objects. For now, I was just wondering whether there was any correlation between the driver instance # for the headset (which is also a game controller) in the registry and the order in which Controller objects were returned in the array after a getControllers() call (since getPortNumber() doesn’t seem to be working). Or should I take another approach to determining the array ordering? Thanks again for the help.
Hi
The order the controllers are returned shouldn’t be relied upon. Currently it may work, but we have no contract (from a software perspective) to keep it this way. I don’t know any instances when the order is not the same as direct input presents them in, but I’ve not thoroughly tested this as it’s not a specified feature.
HTH
Endolf
Endolf, do you know if anyone else has been having problems getting the getPortNumber() method to work in Controller? If I can’t rely on the Controller array order, getPortNumber() seems to be my only other option at this point, and I still can’t seem to get it working on Windows or Linux. Thanks for the help.
Hi
Under both linux and windows it’s not possible as far as I know, using the existing interfaces JInput uses, to obtain the information from the OS as to which port anything is plugged in to.
Endolf