Duplicated/conflicting GUIDs for the DragonRise/PC TWIN SHOCK controllers #202
Comments
Swyter
changed the title
|
@panzergame @DanielGibson If you guys own some of the conflicting controllers, can you dump some USB stats to see if the name/version/revision/firmware fields are somewhat different? I used USBDeview (https://www.nirsoft.net/utils/usb_devices_view.html), but a good old |
|
This is my |
|
I have opened a thread in the SDL2 Development board: https://discourse.libsdl.org/t/duplicated-conflicting-guids-for-the-dragonrise-pc-twin-shock-controllers/24112 |
|
I can confirm this issue. I own a ~10 years old dualshock-style controller and a flight stick that share this GUID. Topway faux-dualshock (not sure about the model): Defender Cobra R4: The difference is very minimal, unfortunately: 1c1
< Bus 005 Device 004: ID 0079:0006 DragonRise Inc. PC TWIN SHOCK Gamepad
---
> Bus 005 Device 005: ID 0079:0006 DragonRise Inc. PC TWIN SHOCK Gamepad
5c5
< bcdUSB 1.00
---
> bcdUSB 1.10
12,13c12,13
< bcdDevice 1.07
< iManufacturer 1 DragonRise Inc.
---
> bcdDevice 1.09
> iManufacturer 0 I don't think you can differentiate them based on that. |
|
I don't want to close this issue for the moment, however this database doesn't have any (direct) ties to SDL itself :/ We are a community effort. As such, problems with the format have to be resolved on the SDL side of things. @Swyter Opening a thread on the SDL forums is the right course of action. For the db, we've had issues popping up about that specific controller from time to time. When it is changed, then a new issue will popup from another user complaining his mappings are broken. etc. while (true) ping_pong_issues(); Since the macOS mapping GUID is different, I will happily accept a PR with it. For the other platform mappings, the best resolution currently is to offer button remapping in your game. It isn't ideal, but it is still a highly recommended thing to do as our mappings are provided by the community and there are probably some messed up mappings in the db. Feel free to keep discussing in this issue thread. Sorry I can't be of more help. |
|
Trust CXT24 gamepad (https://www.trust.com/en/product/17416-gxt-24-compact-gamepad): |
|
Was this ever solved in SDL? Going to close the issue now, you can reopen if you need to. |
|
Hello, as reported here: https://discourse.libsdl.org/t/different-game-controllers-with-the-same-guid/25773... |
|
@clebercasali That's unfortunate, but it has to be resolved in SDL. We have no ties with SDL, we only provide community contributed mappings here. |
|
Hi! |
|
I haven't heard anything new either. I guess the best way would be to open a bug ticket on their tracker. Hopefully this gets resolved at some point. |
|
https://bugzilla.libsdl.org/show_bug.cgi?id=4545 |
Removing `03000000790000000600000007010000` See #202
|
I just found that for some reason the microcontroller of my gamepad seems to dump the entire configurable memory block (its # 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, 0x1000, usb.util.DESC_TYPE_STRING, 0))
b'04030904'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 1))
b'240344007200610067006f006e005200690073006500200049006e0063002e0020002000'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 2))
b'3403470065006e006500720069006300200020002000550053004200200020004a006f00790073007400690063006b0020002000'
>>> binascii.hexlify(usb.control.get_descriptor(dev, 0x400, usb.util.DESC_TYPE_STRING, 3))
b'120100010000000879000600070101020001ffffffffffff0902290001010080fa0904000002030000000921100121012265000705810308000a0705010308000affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff04030904ffffffff240344007200610067006f006e005200690073006500200049006e0063002e0020002000ffffffffffffffffffffffff3403470065006e006500720069006300200020002000550053004200200020004a006f00790073007400690063006b0020002000ffffffffffffffffffffffff05010904a101a10275089505150026ff00350046ff00093009310932093209358102750495012507463b0165140939814265007501950c2501450105091901290c81020600ff750195082501450109018102c0a1027508950746ff0026ff0009029102c0c0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff120100010000000879000600070101020001ffffffffffff0902290001010080fa0904000002030000000921100121012265000705810308000a0705010308000affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff04030904ffffffff240344007200610067006f006e005200690073006500200049006e0063002e0020002000ffffffffffffffffffffffff3403470065006e006500720069006300200020002000550053004200200020004a006f00790073007400690063006b0020002000ffffffffffffffffffffffff05010904a101a10275089505150026ff00350046ff00093009310932093209358102750495012507463b0165140939814265007501950c2501450105091901290c81020600ff750195082501450109018102c0a1027508950746ff0026ff0009029102c0c0ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff'That contains at least;
I wonder if we can hash that and maybe get some unique identifier from it. As you can see the data seems to wrap/end at offset Here is the normally/manually dumped HID descriptor: |
|
If anyone here wants to give it another go and dump their DragonRise gamepad EEPROMs, please run these commands and paste their results here, together with the marketing/model name for your pad and the SDL2 button map. Mine is an NGS Phantom: CC: @DanielGibson, @Akaricchi, @clebercasali. |
Sorry, can't do. Left mine in Ukraine as I fled from the war. Interesting find though. |
|
Well, if this whole EEPROM-dumping mechanism is successful I can use it to make the required generate-an-unique-mapping GUID changes on the SDL2 side as a quirk/workaround. But yeah, thanks for reopening. Made me look into this again. |
|
It’s a neat quirk but seems rather impractical to pursue from a maintenance perspective. Good luck ! |
|
Not really, SDL2 already has low-level The problem is knowing if these boards (and their memory dumps) are actually different internally, that's why I want samples from other people's gamepads. -- I opened my gamepad and saw the bare die wirebonded to the phenolic (read: hardened paper) circuit board under a black epoxy blob, so I don't expect much. That's like musical-greeting-card, cheap-toy-from-the-nineties or smartcard-level packaging; as cheap as it gets. |
|
We're collecting more information on the upstream bug libsdl-org/SDL#3197, can people please post a description of their controller and the output of this script: #!/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 |
|
Please also share your HID reports and run the following Python script, if possible: |
|
I have this exact same problem. I bought 2x DragonRise Inc. "Generic USB Joystick" controller from AliExpress. I'm on Linux Mint with RetroArch/EmulationStation. Both controllers have the same exact name, ID, etc. and therefore can't be distinguished by the software. The only "'unique" thing I could find is the USB port number (where the controller is plugged in). Attached are the outputs of the commands (controller 1 was connected to Bus 003, controller 2 was connected to Bus 004): bus003_addr004.txt Any help would be appreciated. |
|
I've found a usable workaround - in case anyone wants to use the same controller with the same amount of buttons: just wire up the buttons to the board in the exact same order. Then configure one of them in RetroArch - because the buttons are wired up the same, both controllers will work (separately). I've also tried using (the legacy) linuxraw input option which uses |
|
There's a similar situation with "Piranha xtreme", "Trust GX 28", and a Snakebyte SB00566 controller that I found a while back. VirtualBox IDs it as The devices dir for this doesn't contain a manufacturer or serial file, just the following (Fedora 36): The Windows entry now lists it as "PS3 Controller": |
|
What we should probably do is remove both entries and add new mappings including the CRC. Do you have any of the affected devices? |
|
Yes, I still have the Snakebyte SB00566. What should I do? I edited the Python script to force it to use the correct device and tried again. This is the output: Side note: I tried this on in Mac OS 10.6 and got edit: usable portions of the outputs of the other recommended commands: |
|
Mac OS 10.13 GUID is edit: also, the mappings seem correct for my specific controller except for the Windows mapping, which incorrectly assigns righty:a5 instead of righty:a3. |
|
Since the goal of mapping is normalizing the layout and there is no viable "norm" here, we (as well as the upstream project) are omitting mappings for this VID+PID and calling the issue closed. Valve has usage data via Steam Input and so could provide a suggestion for the most useful mapping based on user submitted data, but they do not publicize that information. |
For example, the DragonRise Inc. Generic USB Joystick See mdqinc/SDL_GameControllerDB#202 for details
For example, the DragonRise Inc. Generic USB Joystick See mdqinc/SDL_GameControllerDB#202 for details (cherry picked from commit 673bc57)
|
We're removing upstream mappings for this controller as well: |
For example, the DragonRise Inc. Generic USB Joystick See mdqinc/SDL_GameControllerDB#202 for details (cherry picked from commit 673bc57) (cherry picked from commit c4a493d)
Turns out that many generic Chinese controllers based on the same PC TWIN SHOCK board from DragonRise Inc. share the same USB vendor (
0x0079) and product (0x0006) identifiers, but they also use slightly different button layouts, causing conflicts because the SDL2 gamepad GUID cannot distinguish between them.My NGS Phantom mainly conflicts with #86 in Linux, and the "G-Shark GS-GP702" in Windows. Funnily enough in macOS looks like the GUID is slightly different, for some reason.
These are the correct mappings for Linux, macOS and Windows:
I ship a game with these community mappings and I'm having trouble playing with my own controller because everything is subtly broken.
PS: Maybe Ryan C. Gordon can add some additional optional bits to tell them apart. Maybe by optionally matching by VID/PID/Version/Revision/Firmware instead of only VID/PID.
The text was updated successfully, but these errors were encountered: