Hello sir how do i fix this issue on gamenative ,is there a way to add this line in the environment section of the container settings ?
Thank you
My psvita controller through vitapad isn't working on ge 11 nor experimental nor valve 11 but proton em 10 works for some reason
After almost 8 hours trying to fix my controller not working on the steam remote play, this workaround FINALLY made it work again... 😌
Xbox Series Controller
Fedora 44
Steam RPM (from RPMFusion)
Same symptom: controller visible to steam/os, but not working in game...
Adding the "Enable SDL" as DWORD = 0 on registry made it work... Didn't needed any other change/modification...
Lol you're welcome
From: Pedro Carvalho @.>
Sent: Saturday, September 12, 2026 8:38 PM
To: ValveSoftware/Proton @.>
Cc: Ayoub Lakrad @.>; Comment @.>
Subject: Re: [ValveSoftware/Proton] winebus fails to start on Proton 11 — "Failed loading SDL3 library" (sdl2-compat/SDL3), breaks all controllers (Issue #9939)
[https://avatars.githubusercontent.com/u/17789155?s=20&v=4]inceptusp left a comment (ValveSoftware/Proton#9939)https://github.com/ValveSoftware/Proton/issues/9939#issuecomment-5648221753
After almost 8 hours trying to fix my controller not working on the steam remote play, this workaround FINALLY made it work again... 😌
—
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/Proton/issues/9939?email_source=notifications&email_token=A4UOXQYXCBBLBKGJMUK6HK35OWQ5BA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRUHAZDEMJXGUZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5648221753, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4UOXQ6NSBWXEHR5BM7WGDL5OWQ5BAVCNFSNUABFKJSXA33TNF2G64TZHMYTENJQHE4DQOBQHNEXG43VMU5TINZZGMZDQMRVHE32C5QC.
Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOShttps://github.com/notifications/mobile/ios/A4UOXQ3DSJJTWD4PPA6J6WT5OWQ5BA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRUHAZDEMJXGUZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y and Androidhttps://github.com/notifications/mobile/android/A4UOXQZGASZRKFR463VLS3L5OWQ5BA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNRUHAZDEMJXGUZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI. Download it today!
You are receiving this because you commented.Message ID: @.***>
I used PROTON_SDL_ENABLE_JOYSTICK=1 and it works
I'll shed some light on this since I've worked on that Wine code.
if (!sdl_driver_init()) options.disable_input = TRUE; which acts the same as putting DisableInput=1 in the winebus registry). SDL itself is hardcoded to ignore Valve's virtual gamepad (Vendor=28de Product=11ff).The issue in this thread sounds like SDL was crashing on startup in a new version of Proton, so you're disabling SDL manually. Sounds like a fine workaround, but I bet the crash is fixed in the newest Proton or SDL.
By the way, if someone uses Proton outside of Steam, the Steam Input virtual controller is "dead" and won't send any inputs. But it will still be seen by games, which can break games that only respond to "controller slot 1" (if the dead Steam virtual input controller ends up in that slot). An example of such a game is Dark Souls 3.
The Steam Input virtual controller is always registered on the system as long as Steam is running (sometimes it's not created until a game is launched in Steam, but whatever). It can be seen like this (the first result is my real controller, and the second is the virtual Steam Input controller created by Steam, which can be identified by its vendor/product IDs and the fact that it's a virtual device path):
$ cat /proc/bus/input/devices | grep -iE -A 4 -B 1 "Name=.*(Microsoft|Valve|Steam|Xbox)"
I: Bus=0003 Vendor=045e Product=0b12 Version=0509
N: Name="Microsoft Xbox Series S|X Controller"
P: Phys=usb-0000:0f:00.0-3/input0
S: Sysfs=/devices/pci0000:00/0000:00:02.1/0000:03:00.0/0000:04:0c.0/0000:0f:00.0/usb3/3-3/3-3:1.0/input/input38
U: Uniq=
H: Handlers=kbd event14 js0
--
I: Bus=0003 Vendor=28de Product=11ff Version=0001
N: Name="Microsoft X-Box 360 pad 0"
P: Phys=
S: Sysfs=/devices/virtual/input/input39
U: Uniq=
H: Handlers=event15 js1
It's a good idea to set the DisableInput=1 registry key in that case (on Proton 11+) and/or SDL_GAMECONTROLLER_ALLOW_STEAM_VIRTUAL_GAMEPAD=0 (only needed on older versions of Proton).
That will remove the Steam Input virtual controller from games running in Proton outside of Steam. You can verify it by opening wine's gamepad control panel (wine control joy.cpl in the prefix, or opening the control panel itself and clicking on gamepads), and then checking under the XInput tab to ensure that your physical controller is being seen in slot 1.
It's harmless to disable Wine's event-based controller support, since that's exactly what Wine does by default when SDL is available, since SDL itself queries event-based controller inputs too, and most hardware controllers are picked up by SDL, which is Wine's preferred way to handle controllers anyway since it provides a unified way to correctly map button layouts (having built-in mappings for a vast amount of controllers: https://github.com/libsdl-org/SDL/blob/main/src/joystick/controller_list.h).
The way to disable the event-based input backend from Wine/Proton is as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\winebus]
"DisableInput"=dword:00000001
Or via command line: wine reg.exe add "HKLM\System\CurrentControlSet\Services\winebus" /v DisableInput /t REG_DWORD /d 1 /f
The Wine/Proton prefix has to be restarted afterwards to make it take effect. You can verify that it's gone via Wine's control panel, to see that the virtual Xbox 360 gamepad is gone.
Note that devices using raw USB HID, like Sony Playstation controllers, high-end flight rudders or racing wheels, etc, run through hidraw instead, which is controlled separately by "DisableHidraw", not "DisableInput". So in most cases you won't lose anything whatsoever by disabling evdev inputs. Especially since Wine's own default behavior is to disable that if SDL is available.
And if anyone's wondering: Bluntly disabling evdev entirely is the correct solution. Because there's no way to ONLY remove a SPECIFIC device based on its vendor/product IDs in Wine/Proton. Winebus doesn't have any filtering like that. The only filtering that exists in Wine is product name-based, but the names of controllers usually end up being generic like "Xbox 360 Gamepad", so multiple controllers may have the exact same name. There's also a big bug in Wine's name-based filtering, which I patched in Wine (slated for Wine 11.19) and reported to Valve (hopefully coming to a Proton 11 sub-release later), which prevents people from using name-based filtering until these fixes land in your Wine versions:
I'll shed some light on this since I've worked on that Wine code.
if (!sdl_driver_init()) options.disable_input = TRUE; which acts the same as putting DisableInput=1 in the winebus registry). SDL itself is hardcoded to ignore Valve's virtual gamepad (Vendor=28de Product=11ff).The issue in this thread sounds like SDL was crashing on startup in a new version of Proton, so you're disabling SDL manually. Sounds like a fine workaround, but I bet the crash is fixed in the newest Proton or SDL.
By the way, if someone uses Proton outside of Steam, the Steam Input virtual controller is "dead" and won't send any inputs. But it will still be seen by games, which can break games that only respond to "controller slot 1" (if the dead Steam virtual input controller ends up in that slot). An example of such a game is Dark Souls 3.
The Steam Input virtual controller is always registered on the system as long as Steam is running (sometimes it's not created until a game is launched in Steam, but whatever). It can be seen like this (the first result is my real controller, and the second is the virtual Steam Input controller created by Steam, which can be identified by its vendor/product IDs and the fact that it's a virtual device path):
$ cat /proc/bus/input/devices | grep -iE -A 4 -B 1 "Name=.*(Microsoft|Valve|Steam|Xbox)"
I: Bus=0003 Vendor=045e Product=0b12 Version=0509
N: Name="Microsoft Xbox Series S|X Controller"
P: Phys=usb-0000:0f:00.0-3/input0
S: Sysfs=/devices/pci0000:00/0000:00:02.1/0000:03:00.0/0000:04:0c.0/0000:0f:00.0/usb3/3-3/3-3:1.0/input/input38
U: Uniq=
H: Handlers=kbd event14 js0
--
I: Bus=0003 Vendor=28de Product=11ff Version=0001
N: Name="Microsoft X-Box 360 pad 0"
P: Phys=
S: Sysfs=/devices/virtual/input/input39
U: Uniq=
H: Handlers=event15 js1
It's a good idea to set the DisableInput=1 registry key in that case (on Proton 11+) and/or SDL_GAMECONTROLLER_ALLOW_STEAM_VIRTUAL_GAMEPAD=0 (only needed on older versions of Proton, since the aforementioned "Valve hack" in Proton 11+ bypasses/skips SDL for the Steam Input virtual controller, so the code never reaches the SDL part where this would be needed).
That will remove the Steam Input virtual controller from games running in Proton outside of Steam. You can verify it by opening wine's gamepad control panel (wine control joy.cpl in the prefix, or opening the control panel itself and clicking on gamepads), and then checking under the XInput tab to ensure that your physical controller is being seen in slot 1.
It's harmless to disable Wine's event-based controller support, since that's exactly what Wine does by default when SDL is available, since SDL itself queries event-based controller inputs too, and most hardware controllers are picked up by SDL, which is Wine's preferred way to handle controllers anyway since it provides a unified way to correctly map button layouts (having built-in mappings for a vast amount of controllers: https://github.com/libsdl-org/SDL/blob/main/src/joystick/controller_list.h).
The way to disable the event-based input backend from Wine/Proton is as follows:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\winebus]
"DisableInput"=dword:00000001
Or via command line: wine reg.exe add "HKLM\System\CurrentControlSet\Services\winebus" /v DisableInput /t REG_DWORD /d 1 /f
The Wine/Proton prefix has to be restarted afterwards to make it take effect. You can verify that it's gone via Wine's control panel, to see that the virtual Xbox 360 gamepad is gone.
Note that devices using raw USB HID, like Sony Playstation controllers, high-end flight rudders or racing wheels, etc, run through hidraw instead, which is controlled separately by "DisableHidraw", not "DisableInput". So in most cases you won't lose anything whatsoever by disabling evdev inputs. Especially since Wine's own default behavior is to disable that if SDL is available.
And if anyone's wondering: Bluntly disabling evdev entirely is the correct solution. Because there's no way to ONLY remove a SPECIFIC device based on its vendor/product IDs in Wine/Proton. Winebus doesn't have any filtering like that. The only filtering that exists in Wine is product name-based, but the names of controllers usually end up being generic like "Xbox 360 Gamepad", so multiple controllers may have the exact same name. There's also a big bug in Wine's name-based filtering, which I patched in Wine (slated for Wine 11.19) and reported to Valve (hopefully coming to a Proton 11 sub-release later), which prevents people from using name-based filtering until these fixes land in your Wine versions:
Same symptom on Kubuntu 26.10 / GE-Proton11-11 — libxkbcommon version mismatch
This may be a different trigger from the original report, but the symptom is identical: Failed loading SDL3 library. followed by winebus failing with 1053.
In my case SDL3 was not missing. strace showed the host library opening successfully:
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libSDL3.so.0", O_RDONLY|O_CLOEXEC) = 40
The failure happens during symbol-version resolution:
libxkbcommon.so.0: version `V_1.10.0' not found
(required by /usr/lib/x86_64-linux-gnu/libSDL3.so.0)
GE-Proton11-11 ships files/lib/x86_64-linux-gnu/libxkbcommon.so.0.9.2 and prepends that directory to LD_LIBRARY_PATH. Host SDL3 3.4.14 (from Ubuntu's sdl2-compat package) requires the newer V_1.10.0 symbols, so loading SDL3 fails even though the file exists.
Reproduced outside Wine:
GE="$HOME/.steam/root/compatibilitytools.d/GE-Proton11-11-x86_64"
LD_LIBRARY_PATH="$GE/protonfixes/files/lib/x86_64-linux-gnu:$GE/files/lib/x86_64-linux-gnu:$GE/files/lib/i386-linux-gnu" \
python3 -c 'import ctypes; ctypes.CDLL("libSDL3.so.0")'
# OSError: .../libxkbcommon.so.0: version `V_1.10.0' not found
# (required by /usr/lib/x86_64-linux-gnu/libSDL3.so.0)
Workaround that keeps SDL enabled:
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libxkbcommon.so.0
With that, winebus starts, the controller enumerates (8 WINEBUS\VID_045E&PID_0B22 entries on a fresh prefix), and it works in-game. This is narrower than Enable SDL=0, which also works but bypasses SDL entirely. Host libxkbcommon 1.13 is backward-compatible with Proton's 0.9.2 consumers.
Possible proper fix: don't ship the old libxkbcommon in Proton's library directory, or keep it off the global LD_LIBRARY_PATH so host SDL3 resolves the host copy.
ge-proton11-11x1 2026-10proton 11.0x2 2026-09proton 9.0-4x1 2026-07SDL_GAMECONTROLLER_ALLOW_STEAM_VIRTUAL_GAMEPADx2 2026-09SDL_GAMECONTROLLER_ALLOW_STEAM_VIRTUAL_GAMEPAD=0x2 2026-09PROTON_SDL_ENABLE_JOYSTICK=1x1 2026-09
I was frustrated to not be able to play with new GStreamer and controllers, so...
Summary: On Proton 11 (Beta), winebus crashes at init with
Failed loading SDL3 library+ a Wine assertion, breaking all in-game controller input. Works on Proton 9.0-4 / 10.0-4. Reproducible across multiple games; the controller is seen by Steam and the OS, ignored only inside games.Tested on Clair-Obscur : Expedition 33, Tunic, ABZU
System: Arch Linux, kernel 6.18 LTS, AMD RX 7800 XT (RADV/Mesa 26.1), Steam Flatpak + Steam Linux Runtime (sniper). Controllers: Xbox One (xpad), DualShock 4 (hid-playstation).
By version (same prefix/hardware): 9.0-4 & 10.0-4 → work; 11.0 → dead, Steam Input on or off.
Root cause (winebus log): winebus.sys loads as a module, then the SDL backend fails —
Failed loading SDL3 library, immediately followed byEXCEPTION_WINE_ASSERTIONin libc, a corrupted stack (Exception frame is not in stack limits), andwinebus failed to start: 1053. The bus never starts, so no controller is enumerated. winebus targets the SDL2 API; in sniper, SDL2 is sdl2-compat loading SDL3 underneath, and the crash originates in that sdl2-compat/SDL3 chain — likely related to the containerized SDL3/sdl2-compat reports.Workaround (fully restores controllers on 11):
Steam Input's virtual X360 pad is then created via uinput and picked up by winebus's evdev backend (the commit
HACK: winebus: Use evdev backend for the Steam Input virtual controllers pathlead me there), bypassing SDL entirely. Without uinput, no virtual pad is created and Steam Input silently does nothing.Steam Flatpak note: On my OS, controllers were invisible to Steam until adding host udev rules (ValveSoftware/steam-devices) + flatpak override --filesystem=/run/udev/data:ro com.valvesoftware.Steam — a separate prerequisite from the crash above.
Attachments:
steam-1903340-sdl_enabled: Logs with SDL enabledsteam-1903340-sdl_disabled: Logs with SDL disabledsteam-1903340-fixed: Logs with SDL disabled + uinput + SteamInputRelated issue (but it's Proton 9/10):