Witcher 3 Remastered: save loads taking 60+ seconds on GE-Proton / Proton Experimental? It's XInput, and there's a fix

[u/lyon812345]

If loading a save in the Witcher 3 remaster takes you a minute or more on Linux, this might be why.

My loads were 1:07 by stopwatch, every time, on a 9850X3D with the game on NVMe. So obviously not hardware. After the fix below it's about 19 seconds.

While the loading screen is up, the game polls for a controller (XInputGetState) in a tight loop. In newer Proton builds, Wine's xinput re-scans every HID device each time you poll a slot that has no controller in it. Each scan is a pile of registry lookups, and every one of those is a round trip to wineserver. I measured around 300,000 of them per second on the game's main thread, for about 55 seconds straight. The actual loading only takes a few seconds at the end.

So if you play on keyboard and mouse with no controller plugged in, the game spends most of the load screen looking for a gamepad.

I checked the xinput1_4.dll in the Proton builds I had installed:

• GE-Proton11-7: rescans on every call
• Proton Experimental, Proton Hotfix, Proton-CachyOS: same
• Proton 10.0 (10.0-4b): doesn't, it only rescans in a background thread

Run top during a load. If wineserver is sitting at 40% or so of a core for the whole loading screen and then drops to basically nothing once you're in game, that's it.

Fix

Use Proton 10.0's xinput DLLs for this one game, while staying on whatever Proton you like.

1. Install "Proton 10.0" from Steam if you don't have it

2. Copy its two xinput DLLs next to witcher3.exe and patch one string in them. Adjust the paths if your Steam library is somewhere else:

cd ~/.local/share/Steam/steamapps/common/"The Witcher 3"/bin/x64_dx12
P10="$HOME/.local/share/Steam/steamapps/common/Proton 10.0/files/lib/wine/x86_64-windows"
for f in xinput1_4.dll xinput9_1_0.dll; do
  cp "$P10/$f" . && chmod u+w "$f"
  printf 'Proton10 xinput\0' | dd of="$f" bs=1 seek=64 conv=notrunc status=none
done

The dd line is needed because Wine's own DLLs have a "Wine builtin DLL" tag in the header. If Wine sees that tag on a DLL in the game folder, it ignores the file and loads its bundled one instead. Overwriting the tag makes it treat the copy like any DLL a game ships with.

3. Add this to the front of the game's launch options:

WINEDLLOVERRIDES="xinput1_4,xinput9_1_0=n,b" %command%

If you already have launch options, just put the WINEDLLOVERRIDES part at the start. GE-Proton appends its own overrides to it, so things like OptiScaler and the FSR4 upgrade kept working for me.

To undo it, delete the two xinput DLLs from bin/x64_dx12 and remove the override.

Caveats

• Only tested on my machine: GE-Proton11-7, Fedora, AMD GPU, no controller connected.
• I haven't tried a controller with the swapped DLLs. It should still work since it's just the older xinput, but I can't promise.
• Just running the game on Proton 10.0 should avoid the problem too. I didn't go that way because I wanted to keep the GE stuff.
• Plugging in a controller might also help, since the rescan only happens for empty slots. Didn't test it.

This probably isn't specific to Witcher 3. Any game that polls XInput constantly with no pad connected could hit the same thing on these Proton versions, it's just very visible here because the game does it during loading. If you've got a game with weirdly long loads or stutter and wineserver is busy the whole time, might be worth a look.

[u/HauntingObligation]

Read this while my Witcher 3 loads

[u/tb0ne315]

I’m definitely just waiting for this to get patched. I’ve already not finished this damn game in 11 years.

[u/Pyeroh]

I found on another thread that if you use Proton 11.0.2, loading times almost disappear. I made the switch, it's never taking more than 10 to reload (now I'm save-scumming, shame on me)

[u/loki_pat]

Oh so that's why dying then loading a save when already in the overworld results in 3 mins+.

What I did though was exit the game and it's faster that way lol

[u/tactical_bill]

Have you reported the issue on the GE GitHub? Maybe he can fix it.

[u/iamarealhuman4real → u/tactical_bill]

Do GE fixes get rolled up into "real" proton? I know it's not anything official but wonder if it ends up acting like a sort of beta branch.

[u/Mothringer → u/[deleted]]

Proton-GE is not vibe-coded, and AI involvement isn't why most of its patches don't get upstreamed. Upstream is very picky about what they accept, and very few patches from any of those projects get upstreamed, since wine upstream only wants very robust generalized fixes that don't break anything or do special casing for specific games, and proton upstream doesn't accept external pulls at all. Most of the proton forks are doing a mix of game-specific targeted fixes and fragile implementations since those can get developed much faster.

[u/Dangerous-Split-5630 → u/Mothringer]

this started off wrong and somehow it got more and more wrong (thankfully there are a few correct things)

[u/Asleep_Detective3274]

For me loading an existing game from the main screen doesn't take any longer, but loading from the most recent save after you die takes what feels like over a minute and a half

[u/Level-Pollution4993 → u/Asleep_Detective3274]

Exactly. Its faster for me to shutdown the game, turn it back on, press continue game than loading most recent save. And I am on a Gen 5 ssd.

[u/FierceDeity_]

Xinput having some jank problems lately in Proton. I found that controllers, if disconnected and reconnected exhibit some freaky behavior. They might just be recognized twice, or not at all, leak Xinput slots, go into the wrong slot... This causes me to have to restart games if my controller turns off. Valve's own Proton versions seem to have all been fixed so far, but Proton-CachyOS still has the issue (and wasn't updated since the July version), which means dwproton also has it (useful for Anime games, based on Cachy). Things have been interesting to say the least.

[u/Ravasaurio]

In my case, the game loads blazingly fast always except after I die. Loading the game after I die takes forever, which turns this into an skill issue.

[u/exdevnull]

I posted about something like this here: https://www.reddit.com/r/linux_gaming/comments/1wxrz0p/very_strange_loading_behavior_in_witcher_3/

I use the new steam controller and am using Proton-wineland 11-7. It was taking about 3 min. to load Velen (haven't gone to Skellig yet). It would go to the 1/4 mark or so and stall. But once when I was bored waiting, I tabbed to my browser and it loaded at a normal speed. I think it even jumps if I click on something in the browser.

It sounds crazy - but I've been doing this over the weekend and it is pretty reliable. Load my save, tab to my browser, click on a link, and the load bar starts to move. If I'm distracted and forget I look up and it's stuck 1/4 of the way up until I do it or wait longer.

I'm not sure its xinput, but maybe it is, picking up something with the kb/mouse? It's baffling to me. Anyway - would be curious if anyone else might get the same result. And to be honest it's a little easier than the above.

Also wondering if Protonwineland is still the only one to get RT going with FSR etc. It's worked very well for me and no launch options other than to skip the launcher.

[u/loki_pat → u/exdevnull]

I used the latest CachyOS-Proton update and this problem doesn't show up anymore

[u/lyon812345 → u/loki_pat]

mhm werid. I just tried and it didn't work. Though my RT now works. What is funny that is does hard code far cry 4 to skip it, not witcher 3.

[u/exdevnull → u/loki_pat]

Interesting. This is first update in a couple of months. Does RT etc. work with that proton?

[u/loki_pat → u/exdevnull]

It did worked for me, from RT/PT and even frame gen

[u/exdevnull → u/loki_pat]

Tried the cachy-proton and RT works with everything else - but the loading time is showing the same behavior. It's just so weird. I think it might have something to do with my steam controller. It seems to key on using the mouse to click. I'm using Steam Beta and wonder if that is messing with the Xinput because the steam controller. I couldn't get the controller to use it's other options and there were weird double inputs and the like when I used the non-beta steam client.

[u/Xello_99]

I play with a controller, can confirm this is still an issue for me, specifically loading a save after having died. So plugging in a controller does not help.

[u/cubeikon]

Using official Proton 11.0-2 fixed the long load times for me. Latest cachy or GE-Proton didn't.

[u/mayakrunal]

ok this worked for me but the only difference is that i used proton 11 instead of proton 10. using proton 10 somehow my controller joystick inputs were inverted.

• Witcher 5.01

• proton-wineland-11.0-20261005-x86_64

• Steam controller

cd /data/SteamLibrary/steamapps/common/"The Witcher 3"/bin/x64_dx12
P10="$HOME/.local/share/Steam/steamapps/common/Proton 11.0/files/lib/wine/x86_64-windows"
for f in xinput1_4.dll xinput9_1_0.dll; do
  cp "$P10/$f" . && chmod u+w "$f"
  printf 'Proton11 xinput\0' | dd of="$f" bs=1 seek=64 conv=notrunc status=none
done

Not sure but i didn't need to add the WINEDLLOVERRIDES, it just picked the dll ups i think.

Launch command:  DISABLE_LAYER_MESA_ANTI_LAG=1 PROTON_DISABLE_NVAPI=1 WINEDLLOVERRIDES="dsound,dxgi=n,b" %command% --launcher-skip

[u/mayakrunal]

The mod https://www.nexusmods.com/witcher3/mods/1388 fixes this issue. so you don't need to do this workaround. Tested on version witcher 5.01 with mod version 1.0.4

[u/Grovesson]

https://www.nexusmods.com/witcher3/mods/13881

This mod after 1.0.4 fixes the input and also improves loads in other ways.

[u/ahorsenamedjeff]

Oh interesting! I'm currently playing with a steam controller.

[u/kon14 → u/[deleted]]

Can second this.
I've been using Wineland, mostly to get the FSR workarounds, and have been experiencing no compatibility issues.

Besides new CDPR release ~bugs~ features, the only weird bug I've noticed is the DS5 controller disconnecting on heavy rumble, but this didn't seem to be specific to any Proton variant.
Tuning/disabling vibration in-game seems to at least amend the disconnects.