Joypad order is inverse in some devices

[geekley]

On Godot 4.1.3; Kubuntu 23.10

I'm using a GameCube controller adapter (generic brand, not official from Nintendo). It's a single device that plugs into USB and has 4 ports for GameCube controllers. On godot, 4 joypad devices for it are reported like this: Name: Nintendo GameCube Controller Adapter, GUID: 03000000790000004618000010010000

@tool
extends EditorScript
func _run():
    for devid in Input.get_connected_joypads():
        var dname := Input.get_joy_name(devid)
        var guid := Input.get_joy_guid(devid)
        prints(devid, '"' + dname + '"', guid)
    pass

The ports are correctly assigned (1, 2, 3 ,4) when running godot unsandboxed. But when using the flatpak version, the joypad device order is reversed (4, 3, 2, 1). Same applies to exported games when I build a simple flatpak wrapper around the exported binary with these permissions (same as Godot):

finish-args:
  - --share=ipc
  - --socket=x11
  - --share=network
  - --socket=pulseaudio
  - --filesystem=host
  - --device=all
  - --talk-name=org.freedesktop.Flatpak

Is it because of this? https://docs.godotengine.org/en/stable/tutorials/inputs/controllers_gamepads_joysticks.html#linux

Controllers can still work without udev support, but it is less reliable as regular polling must be used to check for controllers being connected or disconnected during gameplay (hotplugging).

I assume udev support is not available in Flatpak, even if enabled in the Godot compilation (I even tried building a Flatpak wrapper around the official binary, same result). Is there some way to maybe fix this here or in the Godot source code?

I mean, it's not like a random order - it's always reversed (smells like an upstream bug?). And other flatpak apps, like emulators do recognize it correctly (e.g. Dolphin lists 1 evdev device "concatenating" all ports, + 4 SDL devices for each port; both in correct order).

Has this been tested in any other single-USB multi-joypad devices, like other adapters, etc?

[Eoin-ONeill-Yokai]

Have you or can you try this on 4.2? We recently pushed a input PR that converts axis ranges on devices with bespoke axis configuration that might help with this particular issue.

[geekley]

@Eoin-ONeill-Yokai

Have you or can you try this on 4.2?

Still happens on v4.2.stable.mono.flathub [46dc27791] (inverted) when compared to v4.2.stable.mono.official [46dc27791] (not inverted).