Okay, I had an idea and looked into this myself; it looks like Steam Input reads /dev/hidraw devices by way of udev rules installed in /lib/udev/rules.d/99-steam-perms.rules that make the hidraw devices provided by certain drivers and vendors world-readable; that's what you guys use to create your own virtual controllers, and the disconnect between the real hidraw devices and the virtual event devices made by MG are why we get duplicate controllers. This issue is fixed by creating a blank file, /etc/udev/rules.d/99-steam-perms.rules to override and disable the permissions modifications this does on hidraw devices, and render them unreadable. Steam Input can't read hidraw, it exposes no controllers. This eliminates input duplication in SpeedRunners and likely any other game using Steam Input.
Since my usecase concerns virtual remappable controllers on top of and concealing real controllers, and Steam Input duplicates that effort except only for games inside Steam, I'm going to consider this a thing for MoltenGamepad to fix by shipping a udev rule for its system-wide installation to keep your admirable but opposing and proprietary effort from getting in our way.
tl;dr: Not Your Problem.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
Okay so it looks like you guys have become committed to trying to clean up the weird gamepad situation on Linux in your own way. I think this is a good thing. But since your guys interests are entirely self-contained, it will only ever work inside Steam. I have my own fix already implemented that worked both inside and outside of Steam, and somehow these two efforts have become at odds.
I installed a program called MoltenGamepad to cause all my devices to turn into 360 gamepads. It creates virtual devices via uinput, reads real devices, and translates the events according to its configuration. In order to prevent duplicate events from being sent, when installed in system mode, udev sets the real controllers to mode 0600 and changes ownership to a system user called gamepad. That is to say, the /dev/input devices, both event* and js*. Both unreadable.
So, what is the actual problem occurring? Let's take a game that has come onboard with your efforts, SpeedRunners. What do I expect to happen when I run this game? Well, if I'm playing with my friends, I take out however many of my DualShock 4s I need, turn them on, they connect to my computer. Real devices are created, udev makes them unreadable. MG connects them to virtual devices. Those virtual devices should be all that Steam and the game care about. However, somehow the real device gets read from. My one dualshock 4 is controlling two players, because both the virtual and real devices are being read!
I have no idea what's going on here, I thought this was a bug from SpeedRunners. I reported it and they mentioned Steam Controller support. After some poking around I had the idea to just turn off MoltenGamepad. When I do this, nothing should be able to read from my controller at all. Indeed, if I run Antimicro, it can't see squat. If I run one of my emulators, it can't see squat. But if I run a Steam game... all bets are off. It can see my DualShock 4 somehow!! I don't have any gamepad support turned on at all via the controller settings. And even so, the event and js devices are unreadable! It shouldn't be seeing them!
What sort of wizardry are you guys doing? Are you reading from some sort of alternative interface? And how do I get out of it?
Steps for reproducing this issue: