[BUG]: 8BitDo Pro 2 in XInput Mode misidentified as 8BitDo Zero 2

[Zekromaster]

Describe the Bug

When connecting an 8BitDo Pro 2 gamepad wirelessly in XInput mode, PCSX2 actually loads the mappings for the 8Bit Do Zero 2.

The GUID of the 8BitDo Pro 2 is 050095ac5e040000e002000003090000. This means it should grab the mappings for GUID 050000005e040000e002000003090000 (see also mdqinc/SDL_GameControllerDB#779, a PR I opened thinking this was an upstream issue with the Controller DB).

Other info:

• Adding a mapping that includes a CRC to the gamecontrollerdb.txt, these new mappings are loaded for the controller, meaning PCSX2 sees the "right" CRC
• One of the GUIDs for the Zero 2 in the DB is 050000005e040000e002000030110000, which is identical to the 8BitDo Pro 2's XInput's GUID (modulo the CRC) up to the 24th character

This leads me to think there might be some truncation going on that in turns leads to loading the wrong mapping from the file.

I'm reporting the issue again (#11581) because the previous one was closed as "External | Upstream", which as it turns out it's not.

Reproduction Steps

• Connect an 8BitDo Pro 2 wireless gamepad to your computer
• Start PCSX2
• Open gamepad config
• See that the mappings are all wrong

Expected Behavior

No response

PCSX2 Revision

v2.1.83

Operating System

Linux (64bit) - Specify distro below

If Linux - Specify Distro

Fedora 40

Logs & Dumps

No response

[refractionpcsx2]

This is an upstream issue, not something PCSX2 deals with, you need to report it to here https://github.com/mdqinc/SDL_GameControllerDB

[Zekromaster]

No, it's not. Read the linked PR to upstream. The game controller DB contains the right IDs, PCSX2 is outright picking the wrong GUID for the controller.

[refractionpcsx2]

But PCSX2 just asks SDL what the controller is, using that DB, PCSX2 has no concept of what controllers are what, and it certainly doesn't keep its own database, we receive the file from upstream and use it directly, we don't modify anything. So if yours is modified, either you have an old one some how or you modified it.

If there's a duplicate GUID, that's just tough luck, nothing can be done about it, especially from this end, it'll be SDL or the controller DB that has to fix it

Edit: Just checked, the CRC he pointed out doesn't exist in PCSX2's copy of the database, so i dunno where you you got it.

[Zekromaster]

Yes, I mention the thing with the CRC in the issue:

Adding a mapping that includes a CRC to the gamecontrollerdb.txt, these new mappings are loaded for the controller, meaning PCSX2 sees the "right" CRC

The matching logic is not part of game_controller_db.txt. There's no duplicate GUIDs - there's two mappings:

• One for 050000005e040000e002000003090000 ("Xbox One Controller")
• One for 050000005e040000e002000030110000 (8BitDo Zero 2)

By looking at them one on top of the other you can clearly see that they start to differ around the 24th character.

When you connect a controller with GUID 050095ac5e040000e002000003090000, PCSX2 does the following:

• If there's a mapping for the exact GUID, including CRC, it takes that
• Otherwise, it's taking the mapping for 8BitDo Zero 2, when it should be taking the one for "Xbox One Controller"

From a summary assessment this could mean the GUID is getting outright truncated at some point. I have no idea how much of that matching logic is directly PCSX2 and how much it leaves to SDL, though. I think this can't be an issue with the database itself though, because it does in fact contain different GUIDs that appear to be correct for the gamepads involved.

[F0bes]

I'm not convinced it's a PCSX2 issue.
We set the SDL_HINT_GAMECONTROLLERCONFIG_FILE hint, initialize SDL and poll SDL for events.
We don't do the GUID / CRC enumeration, that is purposely abstracted away by SDL.

[Zekromaster]

Ok, this is... surprising. Not sure if it's indicative of a PCSX2 issue or an SDL issue (from what you say it could be SDL) but it seems like I can't reproduce the issue with a file that only contains mappings for 050000005e040000e002000003090000 and 050000005e040000e002000030110000. So I basically binary searched until I found a mapping that needs to be there to break everything.

This is the minimal file I need to reproduce it:

050000005e040000e002000030110000,8BitDo Zero 2,a:b0,b:b1,back:b6,dpdown:+a1,dpleft:-a0,dpright:+a0,dpup:-a1,leftshoulder:b4,rightshoulder:b5,start:b7,x:b2,y:b3,platform:Linux,
050000005e040000e002000003090000,Xbox One Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b10,leftshoulder:b4,leftstick:b8,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b9,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,platform:Linux,
050082795e040000e002000003090000,Xbox One S Controller,a:b0,b:b1,back:b6,dpdown:h0.4,dpleft:h0.8,dpright:h0.2,dpup:h0.1,guide:b8,leftshoulder:b4,leftstick:b9,lefttrigger:a2,leftx:a0,lefty:a1,rightshoulder:b5,rightstick:b10,righttrigger:a5,rightx:a3,righty:a4,start:b7,x:b2,y:b3,platform:Linux,

The moment you remove the XBox One S Controller mapping it breaks the matching.

So... something that strikes me as weird is that the XBox One S mapping does in fact include a CRC. I wonder, is it possible that the presence of two mappings differing only by CRC makes whatever logic does GUID->Mapping break?

Whatever it is, if PCSX2 is leaving literally everything to SDL, and this behaviour clearly isn't documented as the "correct" one by SDL, then it can't be a PCSX2 issue, feel free to close and sorry.

[F0bes]

It might be best to report this upstream to SDL.
If they say it's fine on their end, a further investigation here can take part and this issue can be re-opened.
Thanks for taking the time to investigate 👍