@Guyver1wales What do you mean by this?

I do not get this behaviour at the desktop.

@Guyver1wales What do you mean by this?

I do not get this behaviour at the desktop.

It means I only get the stuttering/lag in-game and not on the desktop.

@Guyver1wales Ah, that makes sense. Thank you :)

The mouse stutter also appeared for me in FFXIV after around 40 minutes.
https://streamable.com/f8x4e
(Stuttering camera is mouse input, smooth motion is keyboard input as a comparison)

Artix Linux with kernel 5.4.2-6-tkg-bmq, replaced DXVK .dlls and RADV/ACO via mesa-git

having the same issue after playing ~1 hour of Enderal (mod based on Skyrim Old Edition), using D9VK

Fedora 31, 5.3.14-300.fc31.x86_64 #1 SMP Mon Dec 2 15:41:35 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
nvidia RTX 2070, 440.36 drivers

I'm also having this problem on Final Fantasy XIV

archlinux 5.4.2-arch1-1 #1 SMP PREEMPT Thu, 05 Dec 2019 12:29:40 +0000 x86_64 GNU/Linux
nvidia 970 440.36 drivers

Same issue with Hitman 2 after this Proton update

Happens in Monster Hunter World in about 20 minutes for me. This is absolutely ridiculous. And I can't downgrade because the previous version (4.2) doesn't run the game.

Also noticed this on "Borderlands GOTY Enhanced (729049)" and "Borderlands 2 (49520)".
OS: Manjaro XFCE
System in a gist: https://gist.github.com/7HEPOW/9b65da0a8d56aa928762d7c57891925b

I noticed this issue in Killing Floor 2 after playing for a hour.

Gist system info: https://gist.github.com/Zlopez/1433022f5f75aebc3155a622997b2997

Happened to me as well with Halo: Master Chief Collection / Reach after about thirty minutes.

Smooth mouse during gameplay and then suddenly it seems as if the mouse input begins to jump in the direction of movement, rather than glide smoothly. The game itself was not lagging, just the mouse input.

This behaviour did not persist when Alt+Tabbing to the desktop.

Happens in Monster Hunter World in about 20 minutes for me. This is absolutely ridiculous. And I can't downgrade because the previous version (4.2) doesn't run the game.

I think you can use custom builds like Glorious Egroll's with it.

https://github.com/GloriousEggroll/proton-ge-custom/releases

Hey, it would be really helpful if you could check which process consumes most CPU time when you experience slowdowns. Cheers.

This is not a framerate issue. It's the mouse input that emits this behavior. Animations in the game are still fine and smooth.

Even if the game itself has a stable framerate, other processes are involved and they could throttle the input due to high CPU usage. It could also be helpful to have information about the mouse brand and model you are using.

Guys can you just stop questioning why and please just check the CPU usage :)

This is not a framerate issue. It's the mouse input that emits this behavior. Animations in the game are still fine and smooth.

I can compile programs in background and still have smooth framerate, this doesn't really mean anything (because i use PDS scheduler).
Please just provide some info regarding resource usage to help developers investigate what could be causing this.

Guys can you just stop questioning why and please just check the CPU usage :)

I'll do it, but it would likely help your case if you'd offer at least some sort of explanation as to why you think this information might be useful. Speaking to people as you are at the moment isn't really helping your cause.

By other processes I meant other wine processes, such as wineserver. Having a high CPU usage there wouldn't necessarily mean having a bad framerate ingame.

Thanks for reporting, everyone. To work around this in the meantime, I've made a "proton-4.11-9" branch of the Proton 4.11 tool which you can opt into. In the Steam client, right-click on the Proton 4.11 tool in your Steam Library (make sure Tools are visible in your Steam library); choose the BETAS tab; and select proton-4.11-9 from the dropdown list. You may need to restart the Steam client for this beta branch to appear.

Distro:Pop!_OS 19.04
Kernel:5.0.0-31-generic
RAM:64 GB
GPU Driver:4.5 Mesa 19.0.8
GPU:Radeon RX Vega 64
CPU:AMD Ryzen 7 2700X Eight-Core
Mouse: Easterntimes Tech X-08 Wireless

System Resources load at time of problem occurrence sorted by highest CPU usage (CrBrowserMain = Halo: Master Chief Collection.)

Did you make a screenshot of this while actively moving the mouse in the active game window?

Did you make a screenshot of this while actively moving the mouse in the active game window?

You're getting close to magical performances there... Though I think that task manager isn't showing threads as such. I'm going to try to reproduce now and see if I can make a screenshot of it.

Ok I've had the task manager open and there is no change before the mouse stutter to when the mouse starts to stutter. Screenshots of the task manager are meaningless as such.

Surprisingly the CPU levels are 20% higher in town than in maps:

And before anyone asks, this was made while moving the mouse.

I have the same problem, playing Ark Survival Evolved after one hour of playing.
The System is not stuttering only the game, i changed different Kernel and play some time but the stuttering came back.

System manjaro linux, all updates
OS: Manjaro 18.1.4 Juhraya
Kernel: x86_64 Linux 5.3.15-1-MANJARO / Kernel x86_64 Linux 5.4.2-1 Manjaro
Packages: 1419
Shell: bash 5.0.11
Resolution: 3840x1080
DE: KDE 5.64.0 / Plasma 5.17.4
WM: KWin
GTK Theme: Breeze-Dark [GTK2/3]
Icon Theme: Flat-Remix-Dark
Font: Noto Sans Regular
Disk: 463G / 929G (53%)
CPU: Intel Core i5-7500 @ 4x 3.8GHz [38.0°C]
GPU: AMD Radeon (TM) RX 480 Graphics (POLARIS10, DRM 3.33.0, 5.3.15-1-MANJARO, LLVM 9.0.0) RAM: 4296MiB / 15980MiB

@GoLD-ReaVeR @Hielyr
Could you show results from perf top when it happens?

Just an opinion, I don't think it's a system resource issue; in Skyrim SE if I move around using my keyboard, there's no jitter, only mouse movement causes the screen to jitter.

Same thing for me, I experience this problem since last Proton update, on multiple games like Killing Floor 2 or Deep Rock Galactic.

I think what they did to improve performance for some games broke something in Proton

Major improvements to mouse handling. In our testing, this improved Fallout 4, Furi, and Metal Gear Solid V mouse behavior.

Here are my specs: https://gist.github.com/Zorrototo/533bb4f3b9d8d5abc137cd8cf5c00f02

@GoLD-ReaVeR @Hielyr
Could you show results from perf top when it happens?

Game:

wineserver:

And I checked for reference, wineserver has no change in behavior. Monster Hunter World when it just started looks like this:

Also having this in Deep Rock Galactic

While the beta branch does seem to resolve the issue for me, it seems to also prevent me from playing Halo MCC, which is a game that had the mouse stutter issue for me.

Yes the issue is absolutely not related to performance, it is clear when you experience it, it is exactly like it takes mouse inputs every 0.5 seconds instead of 'continuous', and it positions your camera in like a 'serrated' wheel pattern.

Yep, I can confirm I'm having the same issue with the newest proton. Everything is butter smooth, the movements, the animations, except when you move the mouse, instead of a smooth motion, it skips from one position to another.

Also, the problem only appears after some time playing the game(s). Restarting works.

My specs are an AMD Ryzen 3600, and GeForce 2070-S.

Thanks for reporting, everyone. To work around this in the meantime, I've made a "proton-4.11-9" branch of the Proton 4.11 tool which you can opt into. In the Steam client, right-click on the Proton 4.11 tool in your Steam Library (make sure Tools are visible in your Steam library); choose the BETAS tab; and select proton-4.11-9 from the dropdown list. You may need to restart the Steam client for this beta branch to appear.

quoting back the reply here in case people didn't see it yet.

Thanks for reporting, everyone. To work around this in the meantime, I've made a "proton-4.11-9" branch of the Proton 4.11 tool which you can opt into. In the Steam client, right-click on the Proton 4.11 tool in your Steam Library (make sure Tools are visible in your Steam library); choose the BETAS tab; and select proton-4.11-9 from the dropdown list. You may need to restart the Steam client for this beta branch to appear.

After i change to the proton 4.11-9 Version as you reported, i could play today 4h without any stuttering.

Could you test if blocking Steam overlay module via LD_PRELOAD=gameoverlayrenderer.so %command% works around the issue for you?

I think i can, but i am now on the older Proton Version and there all is fine.
I test it later.

⁣Gesendet mit BlueMail ​

Am 16. Dez. 2019, 12:52, um 12:52, aufkrawall [email protected] schrieb:

Could you test if blocking Steam overlay module via
LD_PRELOAD=gameoverlayrenderer.so %command% works around the issue
for you?

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ValveSoftware/Proton/issues/3316#issuecomment-566029661

Could you test if blocking Steam overlay module via LD_PRELOAD=gameoverlayrenderer.so %command% works around the issue for you?

Actually, I'm currently suspecting an issue with gameoverlayrenderer. I believe that launching games with LD_PRELOAD= %command% could be a possible workaround, if anyone wants to give it a try.

One of you says

LD_PRELOAD=gameoverlayrenderer.so %command%

the other one says

LD_PRELOAD= %command%

As far as I could see, the default value for LD_PRELOAD environment variable is a path to gameoverlayrenderer.so libraries, I don't know what LD_PRELOAD=gameoverlayrenderer.so %command% was suggested for, but I instead suggest to force the environment variable to be empty so that this shared library is not preloaded.

I basically came up with this due to the lack of something better. Anyhow, I of course checked whether the module actually was loaded then, which it was not.
It btw. once also helped me with the same issue, but in conjunction with Gallium Nine.

So it would appear to me that loading this module by default, despite of turning off the overlay in a game's Steam options, might not be good practice by Proton?

Have the same problem with Quake Live.
QL has three mouse input backends that you can choose with the in_mouse cvar.

in_mouse -1 // Windows cursor API
in_mouse 0 // disable mouse input
in_mouse 1 // DirectInput API
in_mouse 2 // WM_INPUT (raw)

Only DirectInput and WM_INPUT are affected. There is no more lags when reverting to cursor API.

Hence the issue title here.

i have the same issue with Warframe! it started with 4.11-10

@aeikum 4.11-9 is without stuttering. But then another Issue appears, mouse movement to the right or downwards are 30-40% faster than movement to the left or upwards. So if I in Natural Selection 2 move the mouse in a circle, after 6-7 times I've turned 90° to the right and am looking straight down in the floor. The issue does not appear in the main menu.
I tried comparing with Proton 4.2-9, but the game gets stuck in the loading screen before the main menu.

I see the beta has been removed, but this issue is still open. What's going on?

@GoLD-ReaVeR 4.11-11 was released and it supposedly fixes this. I played for a couple of hours with no stutter so it does seem fixed.

Played 3 hours without issues, can confirm it seems solved.

Same here, played 2 hours of Killing Floor 2, Deep Rock Galactic, and no issue regarding the mouse movement.

I started MHW and the game crashed within 10 minutes, I will try again later.

I've made a "proton-4.11-9" branch of the Proton 4.11 tool which you can opt into.

After playing BFBC2 for a few hours today I noticed a mild case of the mouse stuttering, and later went to see if the 4.11-9 branch was still selected... but it's missing entirely.
I'm not sure if I should be reporting that I still have the problem, or if my system just had some other kind of minor tangle happening. But without the 4.11-9 beta to opt into I can't test either.
Just saying.

Maybe you can retest again the 4.11-11 then?

Same here, there was a problem with 7 days to die using proton, after a few hours the mouse starts jumping without loss of visual performance. It seems fixed now.

Can confirm the new version of Proton fixed the issue in Killing Floor 2 for me.

I thought I switched versions but apparently the game was forced to the latest still. So the crashes seem to be specific events in the game as I've managed to play 7 hours straight without a crash. Yet today I received such a crash when fighting Lunastra on Wildspire Wastes. The mouse issue is gone for me.

I've played Monster Hunter: World for about 4 hours with Proton 4.11-11 and this problem is not reproduced, seems it's fixed, at least for MHW. :smile:

Maybe you can retest again the 4.11-11 then?

My point is: I was using 4.11.9 because 4.11-11 was a problem, and after noticing the stutter had returned I checked if my setting of 4.11.9 was still in effect. It wasn't, but now I can't even re-select it, and (based on several hours BFBC2 yesterday) current 4.11-11 stutters too - albeit less.
So obviously I'll be testing 4.11-11 more, because there is no alternative.
The really annoying part is that it's often such a subtle problem that it takes me an hour or two to notice that it's been making it progressively harder to play for that entire time. It's mentally and physically fatiguing in a way thats incredibly tedious and very frustrating after I realize.

Install a custom Proton build then, you can do this by downloading for example one from GitHub at https://github.com/GloriousEggroll/proton-ge-custom/releases or download a specific build from Steam like in this example I made here http://www.redorchestra2.fr/omano/bludit/steam-downloading-and-adding-custom-proton-build my example is for 4.2-5 but go to SteamDB and do as in the example, go to Proton 4.11 SteamDB page, and then in the depot, then select the manifest for the specific build version (4.11-9 being from last week or more). I hope it helps if you don't understand try to find me on Steam for direct message.
edit: so for 4.11-9 you should follow the links in the page https://steamdb.info/app/1113280/ to have the 'numbers' for the download command, Proton 4.11 appID 1113280 then the 4.11 depot 1113281 and then the 4.11-9 manifest 6277836577093277369

Install a custom Proton build then,

Very Excellent info. Exactly what I wanted to know and didn't expect to be able to ask for. Thanks.
ps: pity steam has to make it any more difficult than selecting the desired beta COUGH

Did it work for you?

I think it is fine as it is, though they could have kept the 4.11-9 beta build selectable for some time, but again if they didn't remove it then people wouldn't test the 4.11-11, so.. the custom Proton version is a good alternative. Now if it worked for you, you keep this specific build as long as you want and can select it gloabally or per game.

I downloaded it but cant figure out how to make steam recognise it. Simply copying it to
/home/user/.steam/steam/steamapps/common/Proton 4.11-9-rc4/
(next to /Battlefield Bad Company 2 and Proton 4.11)
evidently doesn't work.

Put it in (create the folder) ~/.local/share/Steam/compatibilitytools.d/

Done. But I'm not seeing any reference it it in Library, nor Proton 4.11 -> betas (where 4.11-9 was before), nor as a specific compatibility tool under BFBC2 properties.
..where should I see/select it?

Restart steam then right click the game > properties > force the use of specific.... You should see it in the list. If not you might of put it in the wrong spot.

ls -l /home/user/.local/share/Steam/compatibilitytools.d/
total 2781740
-rwxrwxr-x 1 user user      12778 Dec 22 17:00  filelock.py
-rwxrwxr-x 1 user user       4933 Dec 22 17:00  LICENSE
-rwxrwxr-x 1 user user      31423 Dec 22 17:00  proton
-rwxrwxr-x 1 user user      90540 Dec 22 17:00  proton_3.7_tracked_files
drwxrwxr-x 2 user user       4096 Dec 22 18:14 'Proton 4.11-9-rc4'
-rwxrwxr-x 1 user user 2848327680 Dec 22 17:30  proton_dist.tar
-rwxrwxr-x 1 user user        215 Dec 22 17:30  toolmanifest.vdf
-rwxrwxr-x 1 user user       1125 Dec 22 17:30  user_settings.sample.py
-rwxrwxr-x 1 user user         29 Dec 22 17:30  version

The folder is there becasue I originally had the files in it, and just now I was trying the files directly in the folder you suggested.
..Still not seeing them in BFBC2 properties though... just 4.11-11

The files are just there? They should be in a folder.

ls -l ~/.local/share/Steam/compatibilitytools.d/
total 8
drwxrwxr-x 3 cheogh cheogh 4096 Nov 22 23:16 boxtron
drwxrwxr-x 3 cheogh cheogh 4096 Oct 22 22:29 roberta

Like i said, did that first, doesn't work either;

ls -l "/home/user/.local/share/Steam/compatibilitytools.d/Proton 4.11"
total 2781736
-rwxrwxr-x 1 user user      12778 Dec 22 17:00 filelock.py
-rwxrwxr-x 1 user user       4933 Dec 22 17:00 LICENSE
-rwxrwxr-x 1 user user      31423 Dec 22 17:00 proton
-rwxrwxr-x 1 user user      90540 Dec 22 17:00 proton_3.7_tracked_files
-rwxrwxr-x 1 user user 2848327680 Dec 22 17:30 proton_dist.tar
-rwxrwxr-x 1 user user        215 Dec 22 17:30 toolmanifest.vdf
-rwxrwxr-x 1 user user       1125 Dec 22 17:30 user_settings.sample.py
-rwxrwxr-x 1 user user         29 Dec 22 17:30 version

same diff when the folder was called:
/home/user/.local/share/Steam/compatibilitytools.d/Proton 4.11-9-rc4/

I gave all the exact steps in my personal notes, in the link I gave you previously. You need to create the compatibilitytool.vdf file.

Read carefully the whole page. Do the steps as explained. if you still fail you're probably doing something wrong, restart from beginning. The fact you're saying you put files in a completely different folder than what I described tells me you didn't read it.

Sorry, I did actually get distracted with the many other documents describing the process less ecomprehensively than yours,.... But the fact that it didn't work the way you described it got me testing various permutations of logic in case you accidentally omitted something. Probably why you assume i just put it in the wrong one and gave up. But nothing I have tried works...and I have tried all of the combinations I imagine as useful.
Currently I have it set as conformant to your description as I can... and have even removed spaces from directory names in case it's that: I have the vdf in both folders right now because it doesn't work individually in any one or the other...and I'm stumped.

ls -al /home/user/.local/share/Steam/compatibilitytools.d/Proton_4.11-9-rc4/
total 12
drwxrwxr-x 2 user user 4096 Dec 22 18:38  .
drwxrwxr-x 3 user user 4096 Dec 22 18:38  ..
-rw-rw-r-- 1 user user  701 Dec 22 18:38 'compatibilitytool.vdf '

ls -al /home/user/.steam/root/compatibilitytools.d/Proton_4.11-9-rc4/
total 2781748
drwxrwxr-x 2 user user       4096 Dec 22 18:39  .
drwxrwxr-x 3 user user       4096 Dec 22 18:38  ..
-rw-rw-r-- 1 user user        701 Dec 22 18:39 'compatibilitytool.vdf '
-rwxrwxr-x 1 user user      12778 Dec 22 17:00  filelock.py
-rwxrwxr-x 1 user user       4933 Dec 22 17:00  LICENSE
-rwxrwxr-x 1 user user      31423 Dec 22 17:00  proton
-rwxrwxr-x 1 user user      90540 Dec 22 17:00  proton_3.7_tracked_files
-rwxrwxr-x 1 user user 2848327680 Dec 22 17:30  proton_dist.tar
-rwxrwxr-x 1 user user        215 Dec 22 17:30  toolmanifest.vdf
-rwxrwxr-x 1 user user       1125 Dec 22 17:30  user_settings.sample.py
-rwxrwxr-x 1 user user         29 Dec 22 17:30  version

compatibilitytool.vdf

"compatibilitytools"
{
  "compat_tools"
  {
    "Proton_4.11-9-rc4" // Internal name of this tool
    {
      // Can register this tool with Steam in two ways:
      //
      // - The tool can be placed as a subdirectory in compatibilitytools.d, in which case this
      //   should be '.'
      //
      // - This manifest can be placed directly in compatibilitytools.d, in which case this should
      //   be the relative or absolute path to the tool's dist directory.
      "install_path" "."
      // For this template, we're going to substitute the display_name key in here, e.g.:
      "display_name" "Proton 4.11-9-rc4"
      "from_oslist"  "windows"
      "to_oslist"    "linux"
    }
  }
}

Don't have two compatibilitytools.vdf files. Restart Steam for any changes to take effect.

With a single file in either directory and not the other.. doesn't work.
As said: I tried it both ways.
Hence the stumped part. :)

and if you call you file "compatibilitytool.vdf" instead of "'compatibilitytool.vdf '" (note the ` characters and space after extension..)

the space

How embarrassing.
mental note: never paste a filename from clipboard... no, better yet adjust my clipboard script to always kill leading/trailing spaces

Thanks. Now I will see if this is actually any better.

I'm not sure if it's relevant in some other way or not, but you might find it useful to edit your tutorial to omit the reference to ~/.local....
Probably simpler to just say "The vcf just goes in the folder with the steamplay tool files" Rather than mentioning ~/.local AND ~/.steam/root... that was slightly confusing/distracting.

I think you get easily confused :P
I give the exact path as it explains exactly where things go, and if you read the paths you can easily see that it is same folder as the previous line.

mkdir ~/.steam/root/compatibilitytools.d/prouton45

Move the content of [..blabla..] to ~/.steam/root/compatibilitytools.d/prouton45

Ccreate the VDF file at ~/.local/share/Steam/compatibilitytools.d/prouton45/compatibilitytool.vdf

It makes more sense to me, and you can't go wrong if you just read, I don't know where it can get confusing. Hope you understand how it works now.

edit: OK I get where it gets confusing to you, ~/.steam/root/ is a link to ~/.local/share/Steam/ so yeah in my notes (actually not really a tutorial this is my hidden blog lol for safe keeping notes) I have the two paths, but this is actually the same folder.

[omano@omano-pc ~]$ readlink -f ~/.steam/root/
/home/omano/.local/share/Steam

same for this link that points to the same place

[omano@omano-pc ~]$ readlink -f ~/.steam/steam/
/home/omano/.local/share/Steam

I edited it to be consistent now it uses ~/.steam/root/

Was there an actual fix for this in any official Proton version?
This still happens in the latest proton builds (6.3-1 and ecperimental) with all kernels above 5.4 on manjaro gnome while playing Borderlands 2.
Not happeining with latest GE builds but has other issues I reported on their discord.

Was there an actual fix for this in any official Proton version?

I'm still using 4.11-9-rc4 for bfbc2.
Every so often I try a newer version and there is always an issue with crashing/stutter/etc.

Was there an actual fix for this in any official Proton version?
This still happens in the latest proton builds (6.3-1 and ecperimental) with all kernels above 5.4 on manjaro gnome while playing Borderlands 2.
Not happeining with latest GE builds but has other issues I reported on their discord.

It's fixed in the 5.13 branch, but broke again on the 6.3 branch. We're working on it, hope to have a fix soon. In the meantime, please use the 5.13 branch if this is a problem for you.

I just re-tried the 5.15-6 i had attempted to use some time back, and after a while playing (maybe an hour) I got noticeable input lag and my framerate showed as 120-200 but absolutely did not feel like it. Nausea was averted by going back to 4.11-9rc

[edit]
Yesterday, because I thought I'd reverted to 4.11-9rc (after the brief test above) I was starting to be concerned that some obscure OS update had messed things up. Vehicles were awful; inputs seemed to be even less than the (feels like) ~25% I usually get on US servers (with my 270ish AU ping). Compared to a local AU server, US servers always feel crappy, but under 5.13 its even worse...turns out I was still using 5.13, but because I was 'sure i had reverted to 4.11-9rc It took an entire days play before I checked.
Switching back to 4.11-9rc today was such a huge difference after being 'forced' to use 5.13 for almost an entire day of play.

[update]
6.3-1 is even worse. It worked quite well for the usual ~10 minutes, then failed dismally.
I suspect it is doing what 5.11/5.13/almost all the other versions do; some of them seem graphically smoothish, yet are obviously dropping inputs.
6.3-1 drops inputs AND visual stutter is very apparent when moving the mouse in infantry mode (not vehicle/mounted gun modes.)
https://bittube.tv/post/8fef273c-1e72-4ea5-921d-85f1a7ae17e9

popped up on proton, cpu spikes to 55ms when moving the mouse, about 5ms if im not moving it. happens in path of exile, risk of rain 2. does not happen in apex or factorio. also the steam overlay stops working for faulty games, so go figure. happens on void linux (fully up to date), on gnome, hyprland 36.0 built from makrennels tempelate, and hyprland built from lastest git

You better open a new issue providing all the necessary info, and referencing this closed issue in a link.