Can confirm this. I first started experiencing this a few days ago with Elden Ring. I've tested it with both Elden Ring and Dark Souls III, and both games the controller does not reconenct to the game if I'm using Proton Experimental, but does if I'm on 9.0-2.

Another thing to note is that the controller touchpad continues to work like a mouse in-game, but all other controls stop working until the game is restarted.

I can also confirm this in multiple games. Did this ever work? I don't recall if it ever did.

(edit) I just ran a test on some random games to see if my controller (DS4) reconnected on any of them; all negative.

• Elden Ring
• Outcast - A New Beginning
• SIGNALIS
• Rain World
• Ori and the Will of the Wisps

I can also collaborate with my findings. This is a very recent regression in Experimental as a few weeks ago this was a non-issue.

No games are able to reconnect gamepads and controllers on my end as well.

I'm planning on looking through commits to see if I can spot the breaking change.

Did this ever work? I don't recall if it ever did.

@abc-mikey Yes this worked fine just last month. See my original comment, reverting from proton experimental back to 9.0-2 fixes the behavior

This is an issue for me now on as well. I’m on a fresh install of Linux Mint 22 xfce edition.

This was not an issue in the past for me when running the same version of proton-GE-11 and Steam beta client on Linux Mint 21.3 xfce. Tested multiple usb ports and multiple games.

yep. issue on my end too, both experemental and GE versions of proton affected to this, switching back to stable 9.0.2 fixes this

yep. issue on my end too, both experemental and GE versions of proton affected to this, switching back to stable 9.0.2 fixes this

If it's also affecting GE versions, can someone see when's the last GE 9 version that it worked for?

Since GE is built off of experimental, this can help narrow down the commit as well

Latest working GE version is 9-10. 9-11 pulled in latest upstream proton according to the release notes and does not work. The last upstream proton merge in GE before that was 9-6, so it would have been introduced sometime between those two release dates. GE 9-10 worked and 9-11 did not when I tried it

Maybe helpful bit of an update, running a game with PROTON_LOG=1, proton experimental gives an error when the controller is re-connected

0088:err:plugplay:IoRegisterDeviceInterface Device interface L"\\??\\HID#VID_28DE&PID_11FF&XI_00#0&0000&0&0&1#{6c53d5fd-6480-440f-b618-476750c5e1a6}" is still enabled.

and seems to think the device is already enabled. This error is absent from the logs with Proton 9.0-2. Maybe proton/wine is not properly destroying the input device in memory when the controller disconnects??

This may be entirely baseless, but something's pulling me to this commit from wine, made on July 3rd and pulled into experimental on July 18th (687a81ed). From my error log message, my device matches VID and PID hex codes of a conditional that was moved around VID_28DE&PID_11FF and corresponding instances of checking if (desc.vid == 0x28de && desc.pid == 0x11ff) ...

Maybe that's irrelevant, but could be a good place to start for someone more familiar with the codebase :shrug:

I have same issue with Super Bit Blaster XL, which is a native Linux game, not using any version of Proton. Strange.

not using any version of Proton.

Then your issue isn't related to Proton @guoyunhe as your issue persists outside of an application running Proton. Your issue looks like a hardware/software issue for your controller. Try xone or try a different controller.

Then your issue isn't related to Proton @guoyunhe as your issue persists outside of an application running Proton. Your issue looks like a hardware/software issue for your controller. Try xone or try a different controller.

The controller works fine with some non-Steam games and emulators. I am still investigating...

I've had this issue for a while now when playing BeamNG.drive via Proton with my Xbox 360 controller: If it disconnects (idle, low battery, whatever), the game doesn't recognize it anymore once it's connected again. Have to restart the whole game so it works again.

Weird thing is: I've already had this problem in the past (end of 2023 I think), then it disappeared, then it reappeared again a while ago.

@Kirschi94 There was a very similar bug in steam for linux back in 2023, could have been that

Oh yeah, pretty sure that was that

Update on my end btw: Hot-reconnection for my 360 controller seems fixed, at least in BeamNG.drive it works again

Controller hot-connection does not work at all for me in "Dragon Quest Monsters: The Dark Prince". If I start the game with my gamepad off and then turn the gamepad on, the gamepad does not work in the game at all. It only ever works if the gamepad was already on before starting the game. It continues to work perfectly in that case, but if it ever times out and I turn it back on, that also doesn't allow it to connect.

Also, when trying to access the gamepad settings in the Steam overlay (shift+tab, then clicking the gamepad icon), the overlay instantly disappears. I can't view the gamepad settings at all. After I've clicked the gamepad settings, opening the overlay shows it for 1 frame and then it instantly starts to fade out and go back to the game. This can be repeated many times if I spam shift+tab.

I saw that this wine bug report was addressed in the latest release of wine: https://bugs.winehq.org/show_bug.cgi?id=57158

I'm guessing that once Proton has the latest changes from wine including the fix in that report, this issue may be resolved.

Thanks for sharing the bug report.

I see the issue was fixed by a merge in wine a week ago.

For me it corresponds to when proton started to work correctly so the change should be already present in Proton.

To be clear:

Now Proton removes the controller correctly once disconnected and recreates it when connecting again.

Whereas, before, Proton didn't reacted to the controller disconnection event and it showed as if it was still connected and upon connecting again it created a new device.

This was the issue that OP referred to as I've seen some other commments mentioning problems that are not related.

I'd say this issue could be closed.

From: Alex Folland @.>
Sent: Sunday, September 22, 2024 12:13:24 AM
To: ValveSoftware/Proton @.>
Cc: Codrut Ban @.>; Manual @.>
Subject: Re: [ValveSoftware/Proton] Controller hot-reconnection broken (Issue #7952)

I saw that this wine bug report was addressed in the latest release of wine: https://bugs.winehq.org/show_bug.cgi?id=57158

I'm guessing that once Proton has the latest changes from wine including the fix in that report, this issue may be resolved.

—
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/Proton/issues/7952#issuecomment-2365337923, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEOW7O7GM3YL6U6PSIMF2TTZXXVQJAVCNFSM6AAAAABLY3PNBWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNRVGMZTOOJSGM.
You are receiving this because you are subscribed to this thread.Message ID: @.***>

I disagree. The issue still happens for me and Proton doesn't immediately take all changes from wine, as far as I know. Like @kisak-valve tagged, this needs a re-test after the change is actually in Proton.

Edit: I just tested with Proton-Experimental, and the issue still happens here, so this definitely should not be closed.

The commit that triggered the regression in Wine does not appear to be included in the Proton fork, so it is quite likely that the fix there will not fix this here, even if the issue seems very similar indeed.

Still an Issue for me

Is Valve working on resolving this issue soon?

Same issue in Proton 9.0.4 (9.0.2 is not available anymore in the drop-down menu)

Using proton 8.x.x fixed it for me (Tested in It Takes Two)

I wonder if this is actually a libsdl2 issue.

With vanilla Wine, I saw a similar issue happening for me again a while ago, when I had built libsdl2 with udev support to test something completely different.

For binary distributions I'd imagine that support to be always included, so most users would probably be affected.

Perhaps a long-ish-shot, but it's something to consider, I maybe guess.

Happy New Year everyone, issue is still there

Did a whole bunch of tests on this subject, easilly reproducable and consinstent on my end
(NEEDS CONFIRMATION FROM OTHER PEOPLE)

Test enviroment

Fedora 41, Gnome 47, Wayland
Steam Flatpak (it doesn't really matter flatpak or not, there are still the same working versions of proton on this matter like for regular version of steam and for a flatpak one)
Steam Beta or Stable also does not matter
Dualshock 4 Controller, XboxOneWireless both using Bluetooth (did a last small test with dualshock wired resulted the same, so it doesn't matter wired or not)
Games: Dead Space Remake, Baldur's Gate 3 (picked them because they have built-in support for Dualshock 4 and both regural xinput, which gives an option to exclude SteamInput from the equation when testing)

Now im thinking that the culprit to this issue is a SteamInput system, to be precise interaction of the Proton and SteamInput
Some commit that was merged in the proton broke how proton interacts with SteamInput, am not a developer so don't know what exactly broken, generated log files using PROTON_LOG=1 command line option in the games.
Since you cannot chose a latest working 9.0.2 version of proton I choose a version 8.0.5 which is working as intended, latest working version of GEProton_9-9

Affected Proton versions: stable 9.0.4 (stable 9.0.2 did worked correctly when it was available), Experemental, all builds after GEProton 9-9 (version 9-10 did not work for me as someone stated above)

Steps to reproduce:

1. On affected verison of Proton disable SteamInput system on a game that natively supports your controller. It just works
2. Enable SteamInput and hot reconnection is broken again

Dead Space Remake

Latest stable version Proton 9.0.4
DeadSpaceproton9.0.4c-NotOK_SteamInputEnabled.log
SteamInput off:
DeadSpace_proton9.0.4c-OK-SteamInputDisabled.log

Latest stable working version 8.0.5
DeadSpace_Proton8.0.5_Ok_SteamInputEnabled.zip (zip archive because github dont allow filles bigger than 25 MB)
Latest working GE version
DeadSpace_ProtonGE9-9_OK_SteamInputEnabled.log

Affected Proton builds:
DeadSpace_ProtonExperement_NotOk_SteamInputEnabled.log
DeadSpace_protonExperement_OK_SteamInputDisable.log
DeadSpace_ProtonGE9-22_NotOk_SteamInputEnabled.log

Baldur's Gate 3

Latest working builds:
Baldurs_proton8.0.5_XboxGamepad_OK_SteamInputEnabled.log
SteamBeta_Baldurs3_ProtonGE9-9_OK_SteamInputEnabled.log

Latest affected stable 9.0.4:
SteamBeta_Baldurs3_Proton9.0.4c_NotOk_SteamInputEnabled.log
Dualshock4Wired_Baldurs_Proton9.0.4c_NotOk_SteamInputEnabled.log
Baldurs_proton9.0.4c_XboxGamepad_Not-Ok_SteamInputEnabled.log

Baldurs_proton-9.0.4c_XboxGamepad_OK_SteamInputDisabled.log
Baldurs_proton9.0.4c_OK_SteamInputDisabled.log

Affected GE versions after GE9-9:
Baldurs_protonGE9-10_Not-Ok_SteamInputEnabled.log

did a quick small test afterwards, installed steam anew from the rpm package (without flatpak whatsoever)
issue is still reproducable as expected
SteamRPM_OK_SteamInputDisabeld.log
SteamRPM_NotOK_SteamInputEnabled.log

Happening on Arch Linux as well (Wayland, https://pastebin.com/5yMvL6Cv)
It is as sour described it, every version after GEProton9-9 and Proton 9.0.2 does not work correctly

I tested:

1. Reconnecting when game was launched with controller
   It didn't re-detect the controller
2. Connecting the controller after the game was launched
   It never detected it
3. Friends connecting their controllers with remote play
   It never detected them either
4. Differentiating between bluetooth/usb
   No difference, still never worked

The moment I switched back to GEProton9-9 it worked flawlessly, also to note, this only happens when Steam Input is enabled for games, in games where I have native controller support (no steam input needed), it works fine

The issue with that is remote play, it always requires steam input and with GEProton-9-10+ having broken steam input, it just doesn't work if someone connects with remote play as it will never let them input anything

Also SUPER rarely when I reconnected the controller, but only really quickly, it successfully reconnected the controller
Since I didn't know this issue existed and it took me a while to find it I thought it was just because my controller switched from /dev/hidraw5 to /dev/hidraw6 but when I did it really quickly, it didn't switch and worked as normal, now I don't know what's happening under the hood but that's my guess

I'm happy to provide logs or evidence if needed, just give me a mention

I'd be happy to test any hotfixes and seeing if it works

Replying to https://github.com/ValveSoftware/Proton/issues/7952#issuecomment-2744759417

Pretty much exactly what I am experiencing. Also with Remote Play and everything.

I can confirm that the problem is still here, with Proton GE 27 and Proton Experimental / Hotfix
Works on Proton 8.0-5, but not with anything after that
The game I'm having trouble with is Metaphor: Refantazio

Also confirm the problem on Debian with Proton 9.0.4 and Experimental. Games: Naruto Storm 1 and 2

Also experimenting same problem on Mint. Games: Yakuza Like a Dragon, Wandering Sword.

Still experiencing the issue on Proton Experimental, Proton Hotfix and Proton 9.0-4 in Motor Town: Behind The Wheel
Downgrading to Proton 8.0-5 fixes this issue

Seems to work on some 10 versions (ProtonGE10-9 works for me), can anyone else confirm?

Yay, good news! Seems Proton-GE 10.9 to be working for me too. Also tested Valve Proton 10.1 beta and there reconnect also works fine!

Im having something similar happening running kingdom come deliverance and others on proton 10.0-2 (beta) but is the same for all other versions i have tested. i have steam input disabled and when a reconnect happens the controller shows up and works in jstest-gtk and in system wine control panel but not in the proton control panel for the game tho it exists yust no inputs coming through. even after restaring the game it wont work again. both control panels have only enable sdl ticked. this is a new development because previously i had the same issue as sour-source tho im not 100% on if disabling steam input helped then i yust restarted the game every time it happened. i can only use my controller once per reboot as it is now with steam... im using xpadneo and a xbox elite 2 controller via bluetooth

Edit: using input remapper as a middle man (without actually remapping) works i only have to press apply on every reconnect now + steam input as a remapper does not work

when a reconnect happens the controller shows up and works in jstest-gtk and in system wine control panel but not in the proton control panel for the game tho it exists yust no inputs coming through

When I had this issue with proton 9 GE a telling sign of the issue was in Steam overlay.
When disconnecting the controller it will still show up in the overlay, as if the event wasn't proccessed.
In my case restarting the game would have made the game reecongise the controller.

Out of curiosity, if you restart steam instead of rebooting does it solve the issue ?

Out of curiosity, if you restart steam instead of rebooting does it solve the issue ?

Sadly no only rebooting or using it via input remapper works for me.

Is there anything that would help diagnose this? It's quite the annoying issue, and I'm at a loss of where to even look. Proton-GE 10-25 and Proton Experimental still have the issue for me on every game.

After the supposed fix in Proton 10 (which didn't work apparently), I don't see anyone posting a log from Proton, maybe we could start with that? Set PROTON_LOG=1 and a log file in your home directory should be appear IIRC.

After spending most of the day bisecting, and keeping my room warm with countless recompiles of proton, I've narrowed it down to this commit https://github.com/ValveSoftware/wine/commit/6d25cce4214f1014bf56d04ecad8735b71c090bb. Reverting this commit my controller reconnects without issue, and without using steam input. tested on Proton Experimental (10) and Proton-GE-10. A similar commit was made in Proton 9, which is likely where this originally came from as well, and why it seemed to be fixed for a bit with Proton 10. https://github.com/ValveSoftware/wine/commit/72503e35e55ff0a2d57341bbd3fa60a076e9304c

Merry Christmas!

From 1616aa1acd7921fa87d45d4b561da3c6e020dfb4 Mon Sep 17 00:00:00 2001
From: Flat
Date: Wed, 24 Dec 2025 21:47:31 -0500
Subject: [PATCH] Revert "HACK: winebus.sys: Fall back to non-hidraw devices."

This reverts commit 6d25cce4214f1014bf56d04ecad8735b71c090bb.

Signed-off-by: Flat
---
 dlls/winebus.sys/main.c | 39 +++++----------------------------------
 1 file changed, 5 insertions(+), 34 deletions(-)

diff --git a/dlls/winebus.sys/main.c b/dlls/winebus.sys/main.c
index 658ee10243d..253ca387ced 100644
--- a/dlls/winebus.sys/main.c
+++ b/dlls/winebus.sys/main.c
@@ -443,17 +443,6 @@ static DEVICE_OBJECT *bus_find_unix_device(UINT64 unix_device)
     return NULL;
 }

-static DEVICE_OBJECT *bus_find_device_from_vid_pid(const BOOL is_hidraw, struct device_desc *desc)
-{
-    struct device_extension *ext;
-
-    LIST_FOR_EACH_ENTRY(ext, &device_list, struct device_extension, entry)
-        if (ext->desc.is_hidraw == is_hidraw && ext->desc.vid == desc->vid &&
-            ext->desc.pid == desc->pid) return ext->device;
-
-    return NULL;
-}
-
 static void bus_unlink_hid_device(DEVICE_OBJECT *device)
 {
     struct device_extension *ext = (struct device_extension *)device->DeviceExtension;
@@ -1026,11 +1015,9 @@ static DWORD CALLBACK bus_main_thread(void *args)
             struct device_desc desc = event->device_created.desc;
             USAGE_AND_PAGE usages;
             UINT buttons;
-            BOOL hidraw_enabled;

             usages = get_device_usages(event->device, &buttons);
-            hidraw_enabled = is_hidraw_enabled(desc.vid, desc.pid, &usages, buttons);
-            if (desc.is_hidraw && !hidraw_enabled)
+            if (!desc.is_hidraw != !is_hidraw_enabled(desc.vid, desc.pid, &usages, buttons))
             {
                 struct device_remove_params params = {.device = event->device};
                 WARN("ignoring %shidraw device %04x:%04x with usages %04x:%04x\n", desc.is_hidraw ? "" : "non-",
@@ -1038,27 +1025,11 @@ static DWORD CALLBACK bus_main_thread(void *args)
                 winebus_call(device_remove, &params);
                 break;
             }
-            else if (desc.is_hidraw && hidraw_enabled)
-            {
-                RtlEnterCriticalSection(&device_list_cs);
-                if ((device = bus_find_device_from_vid_pid(FALSE, &event->device_created.desc)))
-                    bus_unlink_hid_device(device);
-                device = bus_create_hid_device(&event->device_created.desc, event->device);
-                RtlLeaveCriticalSection(&device_list_cs);
-            }
-            else /* desc.is_hidraw == FALSE */
-            {
-                RtlEnterCriticalSection(&device_list_cs);
-                if (hidraw_enabled && bus_find_device_from_vid_pid(TRUE, &event->device_created.desc)) device = NULL;
-                else device = bus_create_hid_device(&event->device_created.desc, event->device);
-                RtlLeaveCriticalSection(&device_list_cs);
-            }

+            TRACE("creating %shidraw device %04x:%04x with usages %04x:%04x\n", desc.is_hidraw ? "" : "non-",
+                  desc.vid, desc.pid, usages.UsagePage, usages.Usage);

-            if (device)
-                TRACE("creating %shidraw device %04x:%04x with usages %04x:%04x\n", desc.is_hidraw ? "" : "non-",
-                      desc.vid, desc.pid, usages.UsagePage, usages.Usage);
-
+            device = bus_create_hid_device(&event->device_created.desc, event->device);
             if (device) IoInvalidateDeviceRelations(bus_pdo, BusRelations);
             else
             {
@@ -1402,8 +1373,8 @@ static NTSTATUS fdo_pnp_dispatch(DEVICE_OBJECT *device, IRP *irp)
         mouse_device_create();
         keyboard_device_create();

-        udev_driver_init();
         sdl_driver_init();
+        udev_driver_init();
         iohid_driver_init();

         irp->IoStatus.Status = STATUS_SUCCESS;
--
2.52.0

@Flat Wow - thank you for bisecting!! Unfortunately, I've seen this same thread several times and been unable to reproduce :/

I know that these will seem like silly questions after this long thread full of users reporting the same issue, but here they are ... much faster to answer than the full bisect at least :D When you were testing for the bisect:

• Which specific game were you testing?
• Which specific controller were you testing?
• Was your controller wired or bluetooth?
• How exactly did you test the disconnect/reconnect -- just unplug/replug? Did you wait a certain amount of time? Were you plugging directly into your PC or into some intermediate hardware like a KVM switch?
• Did you have steam input or disabled?
• Did you have any peripherals besides the controller you were testing plugged in? (keyboard, mouse, etc - please be as specific as possible)
• I think you get my line of questioning... feel free to list anything else that might be relevant here 😅

Also, could you please also copy your system information from Steam (Steam -> Help -> System Information and Steam -> Help -> Steam Runtime Diagnostics) and put each in a gist, then include a link to the gists in this issue report? And attaching a log with PROTON_LOG=1 of the failure wouldn't hurt :)

• Which specific game were you testing?

While bisecting specifically, AstLibra and Silent Hill F. I can also reproduce this issue in many other games such as Tokyo Xtreme Racer, Stellar Blade, and likely others.

• Which specific controller were you testing?

2dc8:310a 8BitDo 8BitDo Ultimate 2C Wireless Controller

• Was your controller wired or bluetooth?

It is wireless via a 2.4Ghz USB dongle 2dc8:301c 8BitDo IDLE

• How exactly did you test the disconnect/reconnect -- just unplug/replug? Did you wait a certain amount of time? Were you plugging directly into your PC or into some intermediate hardware like a KVM switch?

I tested the disconnect/reconnect by powering off the controller, by holding the power button, and then turning it back on, waiting 10 seconds while pressing different inputs. The dongle is connected via USB 3.0 on a USB Hub.

• Did you have steam input or disabled?

Steam input was disabled.

* Did you have any peripherals besides the controller you were testing plugged in? (keyboard, mouse, etc - please be as specific as possible)

While testing, I had a custom QMK keyboard plugged in, a SteelSeries ApS SteelSeries Aerox 3 Wireless mouse and a GoXLR.

• I think you get my line of questioning... feel free to list anything else that might be relevant here 😅

Tried unplugging the keyboard and mouse, and they were both detected and function in game again :)

Also, could you please also copy your system information from Steam (Steam -> Help -> System Information and Steam -> Help -> Steam Runtime Diagnostics) and put each in a gist, then include a link to the gists in this issue report? And attaching a log with PROTON_LOG=1 of the failure wouldn't hurt :)

System Info: https://gist.github.com/Flat/76a1fe667e49cec3298f66f59c24f20d
Steam Runtime Diag: https://gist.github.com/Flat/17c42fdc6a8085df0b9de4429b843147
Proton log with WINEDEBUG="+dinput,+xinput,+input,+rawinput,+hid,+setupapi,+ntoskrnl,+plugplay":
steam-1718570.log

@alasky17 let me know if there is anything else that may help with info. Happy to test patches as well. Thanks!

@Flat Thank you so much for all of those details!!! Unfortunately, we have still not been able to reproduce locally, and that is by far the easiest way to triage/fix an issue like this.

I have a few favors to ask to try to narrow down what is different about your setup, because that could lead to a breakthrough ... could you try:

• testing a different WM than hyprland (eg KDE)
• do you have a way to test the controller wired and manually plugging/unplugging it?
• or ideally, do you have an Xbox or PS controller? We have access to a 8BitDo Ultimate Wireless Controller but not the 2C version 😅
• could you unplug all peripherals except the controller, and then ideally test with the controller directly plugged into your PC?

And see if you can still reproduce the same hotplugging issue with all of these variables changed, or if any "fix" the failure?

Chipping in:
I experience the same issue with my DS5 (PS controller). It’s wired, and unplugging/replugging doesn’t help. I’m also using a Wayland tiling window manager (Sway), so I’m starting to suspect the problem might be related to that.

I’m also using a Wayland tiling window manager (Sway), so I’m starting to suspect the problem might be related to that.

I'm on XFCE (X11) and it's happening to me too, so probably not.

@alasky17

I did not test in different WM since the others have chimed in, however I did test with a PS5 DualSense controller, both wired and wirelessly (bluetooth), and after disconnecting or powering off, it was still functioning. Considering the patch I bisected prioritizes hidraw devices, I would assume there is an issue with the 2C's hidraw devices. I also tested the 2C in bluetooth mode instead of 2.4Ghz, and it also worked fine reconnecting. It is only via USB or the USB 2.4Ghz dongle that it will not reconnect.

Chipping in: I experience the same issue with my DS5 (PS controller). It’s wired, and unplugging/replugging doesn’t help. I’m also using a Wayland tiling window manager (Sway), so I’m starting to suspect the problem might be related to that.

No wonder this bug is so difficult to track down, if a PS5 controller works for me, but not others as well.

First off - thanks to everyone for chiming in -- this is indeed quite a puzzle, and I'm not entirely convinced everyone in this thread is hitting the same issue 😅. There are also some games that simply do not support controller disconnection, so we will not be able to fix every failure even in the best case scenario. @Flat thank you for messing around a bit -- that really helps to know how specific the issue is for you.

For anyone else chiming in, I think the basic info we seem to need is:

• specific controller(s) that are impacted
• how exactly are you triggering the failure (unplugging, turning controller off/on, etc)
• specific game you tested with all of these other specifics, since games are definitely variable with regards to how they support hotplugging
• WM(s) that are impacted (or copy your system information from Steam (Steam -> Help -> System Information and Steam -> Help -> Steam Runtime Diagnostics) and put each in a gist, then include a link to the gists your comment
• A log of the failure never hurts :D PROTON_LOG=+hid,+hidp,+hid_report,+plugplay,+rawinput,+dinput,+xinput,+joystick,+setupapi,+input %command%

Based on the bisect from @Flat (thank you again for that!) I have made some custom builds with the blamed commit reverted. I made a build based off Proton 9.0-4 and a build based off current experimental-10.0-20251222. Builds are here with unlock code "hotplug": https://www.codeweavers.com/xfer/alasky/hotplug-issue/

These can be tested by:

1. Put the tarball ~/.steam/steam/compatibilitytools.d (you might need to create that folder)
2. Untar the tarball
3. Reboot Steam so that the new builds show up in your Proton version drop-down selection.

If you test these directly against the equivalent current Proton versions (Proton 9 and Proton - Experimental) I would greatly appreciate hearing your results. Do these builds fix the hotplugging failures you've been experiencing? Please also respond with the bullet points above about what/where/how you were testing. Thank you so much!

Hi @alasky17! I did some testing and want to say that with my devices I didn't see any changes.
Can you look at the google table? I can upload any variation of logs if it could be helpful to you.

Interesting that enabling/disabling SteamInput in the game doesn't fix the problem. So if controller stop working after re-plug then it doesn't help even if on the changed SteamInput config value it was working fine (but only if game was started with such config)

P.S. In the near future I want to ask my friend for Xbox Controller to do additional tests.

@BLaDZer Looking at your table, I don't think you are reproducing the problem that folks are reporting on this thread. It looks like hotplugging is generally working in the games you tested on Proton 10? If you are seeing a hotplugging failure with a specific game, it is better to report on that game issue rather than this general one. Thank you for trying out my builds though :)

@alasky17 a few months ago I've faced same issue with hot-reconnection when played Witcher 3 on my TV using Steam Link (Dualshok + proton 9 + steaminput). As you can see with the tested game (Cult of the Lamb) problem persist in that proton version.

In general, I thought that if this is a problem in the proton, then it is not so important which game to test, but it is important to test different devices (support for specific controller models) and different input types (DInput and XInput) which have different implementation.

And in principle, I was ready to have to test a couple of games, so the list in the Google table is named in advance according to the game being tested :)

I will try 2-3 games more (Astlibra Demo, How to Survive 2, Grim Dawn) but with limited test cases and only proton 9/10. Can you advice me how to improve this test to make it useful?

@alasky17
"proton-10-exp-1222-revert" seems to have fixed my controller hot-plugging issues, I can disconnect and reconnect my controller and it still works in game. I only tested on 3 games (Blasphemous, Prey, Rain World), but on every game I've played in recent memory "experimental" has only worked with a controller if it was connected before the game was launched, if the controller disconnects I have to restart the game to get it to work again.

However, I just tried Deadlock with a controller as it was another game I had on hand, never tried playing it with a controller before, and hotplug works with "experimental"?? Don't know why it's the only exception.

Also, I have a friend running Bazzite KDE who has no issues with hotplug on "experimental" with the exact same controller+dongle.

EDIT: I just tried with umu-launcher too and similarly "proton-10-exp-1222-revert" allows hotplug, "experimental" doesnt

Hi folks - potentially good news :) After looking at the logs, we might have a solution. @Flat @jakkos-net (and anyone else experiencing the Proton 8 -> 9 hotplugging regression) could you please try this build? The lock code is still "hotplug" and you can drop it in compatibilitytools.d just like the revert builds I made earlier. https://www.codeweavers.com/xfer/alasky/hotplug-issue/experimental-10.0-WINEMR682-301371-20260126-p335f21-w7945c7-d6c57d6-v98e0c3-redist.tar.zst

Edit: If you try this build (regardless of whether or not it fixes your issue) - could you please get a log of attempting to hotplug your controller with this build using PROTON_LOG=+hid,+hidp,+hid_report,+plugplay,+rawinput,+dinput,+xinput,+joystick,+setupapi,+input %command%

Potentially the reason that the issue is so specific to a controller/setup is due to differences caused by some custom udev rules. If anyone is experiencing this hotplugging regression and remembers potentially setting custom udev rules, or using a controller configuration tool which might have set those rules on the backend for you, it would be interesting if you could upload your custom rules here. The two most likely places for custom udev rules would be /etc/udev/rules.d/ or /usr/lib/udev/rules.d/

@alasky17 That build works for me! Is there a source for that build public?

steam-1718570.log

I do have these udev rules related to the controller

71-8bitdo-boot.rules.txt

71-8bitdo-controllers.rules.txt

(.txt appended for github upload rules)

@alasky17 the "WINEMR682" build works for me too

could you please get a log of attempting to hotplug your controller with this build using PROTON_LOG=+hid,+hidp,+hid_report,+plugplay,+rawinput,+dinput,+xinput,+joystick,+setupapi,+input %command%

Log from booting Rain World with the controller connected, checking controller input works on the main menu, powering off and on the controller, then confirming it still works on the main menu:
steam-312520.log

custom udev rules

I haven't intentionally set up any custom udev rules but it's possible something in my NixOS config has indirectly. I grepped around a bit in /etc/udev/rules.d/ for "controller", "gamepad", etc and the only relevant looking file was 60-steam-input.rules. I looked at the nixpkgs source and that file is taken directly from from steam: https://repo.steampowered.com/steam/archive/stable/steam_1.0.0.85.tar.gz (steam-launcher/subprojects/steam-devices/60-steam-input.rules) . I've included the names of the other files below in case anything else seems relevant.

@alasky17 Works for me as well, for a BT controller (8BitDo pro 2)

Didn't change anything as far as udev rules are concerned
Here is the log file, let me know if you need anything more

steam-646570.log

@Flat @jakkos-net @Organic-Code Hi folks! We just shipped a Proton Experimental release today that includes the fix mentioned above. You should no longer need to use the "bleeding-edge" branch.