New GUID format in SDL 2.0.5

[slouken]

In SDL 2.0.5 the USB device GUIDs are standardized across platforms to the Linux format.

For example, the Windows GUID gets a 03 prefix (USB) and the VID and PID are split and the final string is removed:
341a3608000000000000504944564944
becomes
03000000341a00003608000000000000

On Mac OS X the device version has been added to the GUID and it has been split similarly:
4c05000000000000c405000000000000
becomes
030000004c050000c405000000010000

[slouken]

I added code to support older mapping GUIDs, so this isn't urgent, but FYI.
https://hg.libsdl.org/SDL/rev/20855a38e048

[gabomdq]

Hey Sam, how do you think we should handle this change here? It's possible now that if people generate mappings with SDL 2.0.5, they won't work on previous versions...but they will work the other way around...should I only accept old style GUIDs? Split the db in two separate files for pre and post 2.0.5?

[slouken]

Maybe split the file? Or remap the guids to the older format before you accept them?

[ticky]

Oh, is this why Steam Big Picture’s mappings ended up with different UUIDs to when I used controllermap? Good to know!

Is there a way to convert mappings? I presume the GUID discards enough information that it’s impossible…

[ticky]

Oh huh never mind, just read your patch, haha!

Maybe SDL_GameControllerDB should normalise to one or both, yeah!

[ed-mw]

So evidently, v2.0.5 doesn't actually support the older mappings?

[ticky]

SDL v2.0.5 is backwards-compatible with the old mapping types, as mentioned in this comment.

[ed-mw]

v2.0.5 was released 6 months ago... that "fix" was made 4 months ago. :-(

[ticky]

Ah, my mistake! Yeah, that’s awkward.

[ed-mw]

The fix seems doable right in my game code on Windows if I read the file and convert the GUIDs before adding them to SDL... then I can use them with the v2.0.5 released version of SDL. Or maybe it'll be easier to just convert the file in advance.

I notice that the last 12 digits of the GUIDs aren't typically 000000000000 on Linux... according to the source code, it appears that the middle 4 digits of those 12 are a "version" number that is available when the device is queried on Linux. That was causing me some confusion here as well ("...standardized to the Linux format...") 8-|

I may have a few devices to submit as well... I have an original "Wingman Rumblepad" and a "Firestorm Wireless" that I don't see listed... maybe a few others as well... not that anyone actually has these devices besides me... ;-)

[ticky]

Conversion might be a good idea - it’d actually be really quite cool if we could somehow convert the existing file here to uniformly have 2.0.5+’s format, and also have a canonical 2.0.4-and-below version! I’m sure a PR with such a solution would be welcomed.

[ed-mw]

Probably the thing to do is to make a v2.0.4 branch and then update the file to use the v2.0.5 format going forward? Updates and additions can be applied to both the old v2.0.4 branch and head. That way, anyone running the latest released version of SDL (v2.0.5) will get mappings that work, and anyone on an older version of SDL can still get the branched copy. I don't know git, so I don't know how to accomplish this, but I can supply the reformatted version of the existing Windows mappings (someone else will need to fix the Mac OS X mappings).

Still, for some reason, all of the Windows mappings (46) are loading into SDL v2.0.5. Only 31 load successfully. Some of those are probably the duplicates reported in the other thread, but the rest are maybe botched somehow? Do you have to include every action for the map to load correctly? I notice some actions are missing on some of the maps, and some of the actions look like "guide:" (no actual mapped button or other control). What is the proper way?

[ed-mw]

As it turns out, of the Windows mappings, 15 are duplicates, so that leaves 31 distinct GUIDs out of 46 entries... so that explains that.

[p-groarke]

I've converted the GUIDs on my fork. I added it as an option in check.py. Testing is welcome :) Cheers.

[p-groarke]

Fork has been merged, both versions are offered now.