Upstream gamecontrollerdb.txt mappings

[offalynne]

Is there a compelling reason gamecontrollerdb.txt changes are not upstreamed to the source repo https://github.com/mdqinc/SDL_GameControllerDB ?

I suppose if there are udev drivers or other changes that make ROCKNIX different than a generic distro this might cause compatibility conflict but surely this is not the case for all handheld device controls ? I think it would be ideal for as many mappings as possible to move upstream

[r3claimer]

We have found that the upstream gamecontrollerdb maintainers to not be easy to work with when trying to submit PRs in the past. Easier to just maintain our own.

[offalynne]

@r3claimer hi :-) i'm a maintainer of the upstream gamecontrollerdb ! glad to work with you (or anyone else involved) to this end :-)

[loki666]

one problem, will be whom is authoritative source for the mapping of a given handheld.
Some retro distrib, will want a modern mapping with button A mapped to SOUTH, and others will want a retro mapping, with A mapped to EAST. (In ROCKNIX it's a UI setting)

So either there will be discussion around that, or distros will end up using different VID/PID/names to their own needs, but then it's not really different from what we already do...
Relying on upstream also creates the risk to break a mapping we carefully created for ROCKNIX.

also, while the gamecontroller db is good for usb/bluetooth devices, so that the mapping is correct as soon as you connect it, for handheld, it's not that usefull, as the builtin controller can only be used with the distro it's running on

[offalynne]

"whom is authoritative source for the mapping"

the authoritative mapping format is prescribed by SDL. regardless of who serves the data or how, there should be no ambiguity in the data or it's format: https://github.com/mdqinc/SDL_GameControllerDB?tab=readme-ov-file#mapping-guide

"Relying on upstream also creates the risk to break a mapping we carefully created for ROCKNIX?

this is a fair concern, but the upstream data is maintained and will not be changed trivially. there's no reason that concern can't move upstream. if this is actually a provable problem, the data can both exist upstream for past and future projects relying on it, and ROCKNIX can keep it's downstream overrides.

your remaining arguments don't hold from my perspective, especially regarding button layout variation (south vs east) which should not be handled at the mapping level. the actual issue, which is categorizing and enumerating controls for best compatibility regardless of downstream use case, is needlessly complicated by fragmenting the source of the data.

if ROCKNIX contributors are not following SDL's mapping scheme i suppose that's as good a reason as any for contributions not to move upstream, which is unfortunate.