I haven’t played Baldur’s Gate 3 myself, but one thing that might cause that:

Linux has two different joystick APIs. By default, at least on my Debian system, both drivers are set to load by default. The older API, joydev, creates a device at /dev/input/js0 (or some similar-such number). The newer one, evdev, will create a device at /dev/input/event0 (or some similar-such number).

You can use jstest to see devices via the joydev API, and evtest to see devices via the evdev API.

Some software uses libraries or the like that can talk to both and will expose both to the application. It looks like Baldur’s Gate 3 doesn’t have a Linux-native release, so I assume that WINE (well, Proton) will expose both as two gamepads.

This wasn’t historically much of a problem, since it was something of a convention in software to not do anything with joysticks unless a gamepad was enabled in the game and the user configured the buttons (which was something of a pain in the neck, but whatever). Part of this was that there wasn’t much of a convention as to which button number did what, which meant that it wasn’t possible for a controller to work reasonably out of the box.

However, on Windows, the XBox controller kind of became something of a standard, and so software started assuming an XBox layout, and so using a controller out-of-the-box became more-common. There have been better ways to figure out what the layout is, as I understand it, but this kinda kicked software to make the jump to “be enabled by default”.

Unfortunately, that meant that sometimes software didn’t let one choose which controller to use, or let one manually configure the gamepad, or choose to ignore an attached gamepad, with the idea that the user was just going to dick it up.

So if you have a gamepad exposed as multiple gamepads, sometimes a software package will just try to be helpful and use input from anything that looks like a gamepad without giving you an option not to do so, which means that you get multiple events if you have multiple “virtual” gamepads being driven by one physical gamepad.

There may be better ways of addressing this – I mean, there probably should be and maybe is a way of dealing with this in WINE, since there’s no reason I can think of that you’d ever want to use joydev devices in software, like WINE, which can handle the evdev interface for a device. If a device is visible via both APIs, WINE should really only talk to it via evdev; Joydev is just kept around for compatibility with old software that can’t talk to evdev. However, one way of solving the problem with a sledgehammer is just telling your machine not to allow use of the joydev driver. The evdev driver has been around for a long time. I don’t personally know of any Linux game that doesn’t support evdev; if there is, I’d guess that it’s probably a pretty elderly, Linux-native, closed-source (either that or not getting very frequent updates) application. You can just blacklist the joydev driver, keep it from loading, and you’ll only get the evdev device. That means that any software around that can only do the old joydev interface won’t work, but I don’t know of anything today for which that is the case.

On my Debian Trixie system, I have a file that does that (IIRC, because I ran into the same issue with Fallout 4, also via the WINE layer producing duplicate input, and with Fallout 4 not having the ability to ignore a gamepad at the application layer):

I created a file, /etc/modprobe.d/joydev-blacklist.conf:

# Gives duplicate events with evdev
blacklist joydev

Next boot, your Linux system will not ever load the joydev driver, and you won’t get any /dev/input/jsX devices.

Arch looks to do things the same way; here’s their documentation for blacklisting a module:

https://wiki.archlinux.org/title/Kernel_module#Blacklisting