Different game controllers, different mappings, same GUID #3197
Comments
|
I have figured out a trick that gives me a very unique signature for each controller. #!/bin/bash |
|
I think I've also run into this problem when using a Wii U Pro Controller and a Wii Remote. My custom mapping for the Wii Remote messed up the mapping for the Wii U Pro Controller and I wasn't able to use both mappings simultaneously. |
|
Quick heads up. I looked into this yesterday and found a way of dumping the entire configurable memory block from DragonRise/PC Twin Shock gamepads through a simple USB string descriptor call. Yes, really. ¯\_(ツ)_/¯ -- We need more samples/dumps of other pads to see if they are unique enough to hash them and make their GUIDs unique via SDL2 workaround. Please take a look at the thread below for a script and instructions to dump your own board using only software, it's really easy and it can make a difference: |
|
Yep, this should do the trick. @Swyter, can you confirm? |
|
@slouken I don't think this will be enough in this case because from the At the very least I think maybe hashing the HID descriptor may be a step up. But we do need more samples to know if this is worthwhile. |
|
Your case should be handled where the DragonRise and Microntek controllers have different names. I see the devices with duplicate names, mdqinc/SDL_GameControllerDB#202 (comment) even has one of them as a dualshock style and another as a flight stick, but otherwise identical. I'm not sure we can do much about this, unfortunately. We don't have access to the underlying HID descriptors on many configurations, and even if we did, we probably don't want to use those as identifying data in most situations. For example, we don't want to mark different Xbox controller firmware revisions as different devices. We could special case that particular VID/PID, but if both are connected at the same time, I'm not sure how we would map USB device path to the event node in Linux, or the DirectInput handle to USB device path on Windows. |
|
@slouken Here it says that you can call
I imagine you'd find something like that for Linux. You could also potentially differentiate them by recording and matching their plugged-in timestamps under both back-ends, I suppose. |
|
Sorry about the delay to answer. |
|
@slouken @icculus The thing is, I would prefer having more hard data from other devices first and then find a solution. Because right now we don't even know if that is even different enough for the large subset of DragonRise devices where that recent pull request didn't make the trick. You guys have physically more resources to acquire and test hardware; I only have a single DragonRise pad with me. And no one seems interested in helping so far. I can't really justify buying more controllers to diagnose this mess in my free time. |
|
We are reliant on community contributions just like you, in this case, getting exactly the right hardware to reproduce is almost impossible because of the age and how misleading sales pages are in what product you're actually getting. I'll leave this bug open so people can contribute more data on what works and what doesn't and we can improve our solution from here. |
|
Out of curiosity, what does this script return for the various controllers? (thanks @clebercasali) #!/bin/bash
DIR=/sys/bus/usb/devices/$(ls -R /sys/bus/usb/devices/* | grep js$1 | cut -d$'\n' -f2 | cut -d: -f1 | awk -F/ '{print $NF}')
IMANUFACTURER=$(cat $DIR/manufacturer)
IPRODUCT=$(cat $DIR/product)
ISERIAL=$(cat $DIR/serial)
IVERSION=$(cat $DIR/version | xargs)
SIGNATURE="$IMANUFACTURER:$IPRODUCT:$ISERIAL:$IVERSION"
echo $SIGNATURE |
|
For the NGS Phantom it outputs this, the # swy: install pyusb (pacman -S python-pyusb) and run python3 as sudo
>>> import usb.core, usb.control, usb.util, binascii
>>> dev = usb.core.find(idVendor=0x0079, idProduct=0x0006)
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_DEVICE, 0))
b'120100010000000879000600070101020001'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_CONFIG, 0))
b'0902290001010080fa0904000002030000000921100121012265000705810308000a0705010308000a'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 0)) # iSerial 0
b'04030904'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 1)) # iManufacturer 1 DragonRise Inc.
b'240344007200610067006f006e005200690073006500200049006e0063002e0020002000'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 2)) # iProduct 2 Generic USB Joystick
b'3403470065006e006500720069006300200020002000550053004200200020004a006f00790073007400690063006b0020002000'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 3)) # swy: overflowed/out of bounds data, also works with 7 or 11
b'120100010000000879000600070101020001ffffffffffff0902290001010080fa0904000002030000000921100121012265000705810308000a0705010308000affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff04030904ffffffff240344007200610067006f006e005200690073006500200049006e0063002e0020002000ffffffffffffffffffffffff3403470065006e006500720069006300200020002000550053004200200020004a006f00790073007400690063006b0020002000ffffffffffffffffffffffff05010904a101a10275089505150026ff00350046ff00093009310932093209358102750495012507463b0165140939814265007501950c2501450105091901290c81020600ff750195082501450109018102c0a1027508950746ff0026ff0009029102c0c0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff120100010000000879000600070101020001ffffffffffff0902290001010080fa0904000002030000000921100121012265000705810308000a0705010308000affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff04030904ffffffff240344007200610067006f006e005200690073006500200049006e0063002e0020002000ffffffffffffffffffffffff3403470065006e006500720069006300200020002000550053004200200020004a006f00790073007400690063006b0020002000ffffffffffffffffffffffff05010904a101a10275089505150026ff00350046ff00093009310932093209358102750495012507463b0165140939814265007501950c2501450105091901290c81020600ff750195082501450109018102c0a1027508950746ff0026ff0009029102c0c0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'That's how I found that index |
|
I can test the above on a common N64 clone pad as well shortly. Pinging @DanielGibson as well from mdqinc/SDL_GameControllerDB#202 |
|
|
|
In my case with the WiiU pro controller and the wii remote, the USB info reflects that of my USB card. ( Since they're not USB controllers, I don't think any USB dumps will be helpful. Here are two mappings I created (the controllers are very different from eachother, so its very noticable when the mapping is confused)
Maybe we could have a way of saying in a specific mapping that the name must match strictly? (That way, this only needs to be changed for these few overlapping controllers). |
|
Can you guys try creating mappings using the latest SDL code in git, with the controllermap test program? |
|
I easily bought a Trust GTX 24 compact gamepad (GTIN-13/EAN: They couldn't change a single byte by chance. I guess this settles it until someone finds a secret HID command that outputs some other motherboard or OEM version marker, albeit at this point that seems highly unlikely. So yeah, for super easy cases where they differ by more than a single byte it should be easy to differentiate, in the case of this pair of Dragonrise pads and potentially way more they are essentially the same product, just wired slightly differently out of pure evilness. Details with the HID report, |
|
Still a worthwhile change for SDL since prior the Windows format lacked any fields besides VID and PID, and the Hori pads Sam wrote this change for are usually identifiable at least by name. Unfortunate but unsurprising re Dragonrise. |
That's exactly what the latest SDL code does. It includes a CRC of the controller name in the controller GUID. If a mapping has a CRC field, it matches any controller with that VID/PID and name. If the field isn't present, then it will match that VID/PID with any name. |
|
I think we've settled on using the CRC of the name and the USB VID/PID as the identifying information that we can use. We don't have access to the report descriptor generally, so any devices that don't change their name or VID/PID from the default for the chipset will have to be mapped by the end user. As noted above, some controllers don't change the firmware at all, they simply wire up different connections on the hardware. I'm closing this for now, feel free to reopen if new information becomes available. |
This bug report was migrated from our old Bugzilla tracker.
These attachments are available in the static archive:
Reported in version: 2.0.5
Reported for operating system, platform: Linux, x86_64
Comments on the original bug report:
On 2019-03-12 18:22:36 +0000, landeel wrote:
On 2019-03-12 21:16:54 +0000, landeel wrote:
On 2019-03-13 14:24:44 +0000, Ismael Ferreras Morezuelas (Swyter) wrote:
On 2019-03-13 21:05:03 +0000, landeel wrote:
On 2019-03-13 21:12:14 +0000, Ismael Ferreras Morezuelas (Swyter) wrote:
On 2019-03-19 21:25:34 +0000, landeel wrote:
On 2019-06-12 03:21:40 +0000, Sam Lantinga wrote:
On 2019-06-12 16:20:35 +0000, Ismael Ferreras Morezuelas (Swyter) wrote:
On 2019-06-12 16:44:22 +0000, Ismael Ferreras Morezuelas (Swyter) wrote:
On 2019-06-12 17:30:17 +0000, Ismael Ferreras Morezuelas (Swyter) wrote:
The text was updated successfully, but these errors were encountered: