@who@feddit.org pointed me to the solution. Since XInput is implemented using SDL2, it can be told to selectively ignore devices by setting the SDL_GAMECONTROLLER_IGNORE_DEVICES environment variable. The value should be a hexadecimal VID/PID pair separated by /, or a comma-separated list of VID/PID pairs for multiple devices.
For the 2026 Steam Controller:
SDL_GAMECONTROLLER_IGNORE_DEVICES='0x28de/0x1304'
For other devices using a USB cable or dongle, the VID/PIDs can be listed using this command:
lsusb | sed -E 's/.*: ID ([a-z0-9]{4}):([a-z0-9]{4})/0x\1\/0x\2/'
There are some non-Steam games that I can’t run through Steam because of its sandboxing (bubblewrap, Steam Linux Runtime, pressure-vessel and such). For those, I’ve set up SISR to capture the SC’s input and remap it to a virtual controller.
While SISR itself works (and quite well with both the touchpads and the gyro), the game ends up receiving inputs from both the virtual and the physical controllers simultaneously.
Running wine control joy.cpl shows both the real SC and the virtual Xbox 360 controllers as DirectInput devices. The XInput list is empty, but the XInput tab shows that it receives input events from both the SC and the virtual controller. Disabling hidraw or the individual DInput devices has no effect.
I’d like to find a way to either hide the device from Wine’s XInput driver, or to prevent the XInput device (within Wine) from sending input events to the game. So far, no luck. Any help would be appreciated.
There are some non-Steam games that I can’t run through Steam because of its sandboxing (bubblewrap and pressure-vessel and such).
Do you mind giving some examples of what kind of issues you’re having here?
I’ve had really good luck with running external games through steam, so I’m just curious what kind of issues you’re having.
Mostly I can only describe it as “game no worky”. Steam pretends to launch a game, then nothing happens. My hypothesis is that Steam does something to the runtime environment that fucks with some games.
One other thing that I’ve noticed is that on Wine/Proton environments launched from Steam, the lettered drives (aside from
C:) are mounted as some kind of overlay filesystem. Writing to them (e.g. by an installer) causes data to be written into memory, not to the mass storage where the drive targets are located.
I had not heard about this one but I may have a use for it. I don’t know the solution to your problem but thank you for posting it.
Why do you need SISR for this? If he game is receiving input from the real stream controller (as you wrote), why not just disable SISR and go along with that?
Anyway, what you can try is to disable one of the controllers in the “Game Controllers” section of control, as outlined here: https://github.com/AntiMicroX/antimicrox/wiki/Methods-for-Disabling-Joystick-Reading-in-Linux
That website also include some more advanced methods, but I don’t think they will apply to your usecase, unless you want to run SISR as a different user.
why not just disable SISR and go along with that?
Because I want to use all inputs on my controller, and (so far) only Steam Input allows me to do that. Without Steam Input, the SC is comparable to an Xbox controller.
I’ve tried most of the methods in the article, to no effect.
