sdl2 guid, remove the CRC bytes (4 first characters) and replace with 0000 when creating guid #753
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: MeloNX/Ryujinx-ryubing#753
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "Tartifless/master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This change fixes issues with controllers changing guid changing with every launch by removing the 4 first chars (crc16) used by SDL that change with every init for xbox controllers.
Fix #751
Fix #687
Fix #577
The solution is simple and is also the one used in other emulators that use the guid in the config file, the trick is to replace the guid section that is not static (that changes with each init of SDL) with 0000 in order to manage with the more common guid (similar to the one found in SDL internal database or in gamecontrollerDB).
As an example:
030056d05e040000130b000009057200 is stored and used in ryujinx with 030000005e040000130b000009057200, this ensures also for the future that this variable CRC16 section is not impacted by future SDL upgrades, as SDL has a tendancy of not knowing how they want to manage this section...
This will also prevent all future changes of CRC16 (SDL2 teams have a tendency to update guid calculation of CRC16 part with every version) to impact people's configuration and saved profiles for their contollers...
It seems that this does not affect compatibility with other gamepads, the only thing is that you need to reconfigure all previously connected gamepads.
You can instead of zeros write a unique identifier for the emulator, for example RYUX and this also works
Why use this when sdl2 guid is with 0000, that would make it specific while 0000 keeps standard sdl
These bytes after their replacement turn out to be meaningless, of course you can leave zeros, but they will not affect anything in the future, including compatibility, except perhaps visual.
For the emulator, this number becomes just a string variable, and then it is simply placed in the list for display in the menu. At least I am currently working on the controller menu and it seems to work exactly like that.
Your gamepad will still connect without problems,
At least I tested it in my assembly and it works great
My recommandation is usually to stick to the standard provided by the library, but i agree that here whatever will work, as it's part of the object...
This is an extract of SDL database commonly used :
Also native methods used in SDL2 library can return the sdl string without CRC16 (0000 instead).
So usually i stick more to the use of what is commonly used, just look at other emulators:
All in all it works, of course people having saved profiles would need to recreate them once, but that's really not an issue versus the issues that XBOX controllers not saving represent.
We could even provide a tool that would automatically go through the profile files and edit the guids to fix this and make profiles compatible without having to recreate them, i highly doubt a huge lot of people actually use profiles in an extensive way.
I've tested with approx 16 controller models (from PS4, dualsense, switch pro, many 8BitDo and Xbox models), and as you already noticed, there is no impact in compatibility of these.
I understand everything. I definitely like that it works and the solution turned out to be simpler than I thought.
Basically, when working with sdl and controllers, first hint will always be the guid, these guys change the way to calculate these crc bytes so often amd with each version that it became a mess, to cover each cases one would need a folder with 8 dll and dynamically retrieve each guid from each version...
But originally we should blame the manufacturers that build controllers and use vid/pid from standard manufacturers instead of their own, especially when they use different button layout than the controller they "copy".
I did not look yet at sdl3, that will be a whole new story (for better or worse but I hope for better).
your solution is good, but there is another problem that unfortunately neither sdl2 nor sdl3 will solve, it is the confusion of two absolutely identical controllers. For the correct detection of such devices, the port number to which they are connected is needed. I looked at sdl3, It is impossible to get the USB port number through these libraries. But this is a completely different problem
I don't think this is a problem, ryujinx adds an index before the guid that increments for identical controllers.
Normally the enumeration order of controllers is the same, as it's based on the device path...
And worst case scenario, someone has 2 identical controllers connected, there would be no issues just picking up the correct one...
@GreemDev , can you have a look at this one ? As first time contributor I guess there are some specific things to do...
Download the artifacts for this pull request:
Only for Developers
Any next step for this one ? I have tested the build and it works, anyone else need to test something ?
Checkout
From your project repository, check out a new branch and test the changes.