Unity-based FPS Games have mouse jumping.

[kisak-valve]

Issue transferred from ValveSoftware/wine#20.
@AmandaCameron posted on 2018-09-12T18:33:26:

As mentioned in This comment for Subnautica there's some mouse issues where there's unexpected movement during mouse button presses. I'm experiencing a very similar issue in Stationeers (APPID: 544550) so I suspect it's got something to do with unity3d, which both games use.

---

@kisak-valve commented on 2018-09-12T18:42:32

Hello @AmandaCameron, please copy your system information from steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report. Additionally, what model mouse are you using?

---

@AmandaCameron commented on 2018-09-12T19:01:48

Appologies:

System Info

The issue happens with both the UHURU Bluetooth Mouse as well as the touch-pad built into my laptop.

[kisak-valve]

Mouse Problem on Many Unity-Based Games.

Issue transferred from #1424.
@fcmonter posted on 2018-09-13T02:30:45:

steam-444490.log

#Games

• Anything Unity Engine Based;
• Games i'm sure of, The Forest, Polywar

#Specs

• GPU: GTX 1060
• Driver Version 396.54
• Kernel version: 4.15.0-34-generic
• https://gist.github.com/fcmonter/bdd21ee912d7f840eb55b9e14b7ba771
• Proton version: 3.7.6 BETA
• Steam log of game is of Polywar

Whenever I play any unity-based game on any computer on any Linux distro, whenever I would move the mouse up, it would move to the right a little bit. Overall the mouse would just do weird things.

To reproduce this I guess just play a unity game.

Here is a reddit post of some people having the same issue
https://www.reddit.com/r/linux_gaming/comments/9ajw3j/mouse_problems_with_proton/

---

@nanonyme commented on 2018-09-13T07:10:07

Duplicate of #1418?

---

@fcmonter commented on 2018-09-13T11:24:55

Duplicate of #1418?

I don't think so.. but i'm not sure.

---

@byte1024 commented on 2018-09-13T14:16:58

Will kisak-valve close it or not? That is the question lol

---

@dreamer commented on 2018-09-13T14:27:52

@fcmonter I tested one or two Unity titles and didn't experience this problem (but not the ones you reported). This sounds awful like #831 (which was fixed in 3.7-6).

---

@fcmonter commented on 2018-09-13T14:30:11

@fcmonter I tested one or two Unity titles and didn't experience this problem (but not the ones you reported). This sounds awful like #831 (which was fixed in 3.7-6).

Well I'm not sure what to do, and the games they tested were not unity-based.

---

@dreamer commented on 2018-09-13T14:32:17

Did you try to run Unity games in the native resolution of your display? That was a workaround for 831.

---

@Quinnux commented on 2018-09-13T14:42:40

This bug is reported as present in My Summer Car #880 (which is a Unity game) - if you click a mouse button, or move the scroll wheel, your view shifts down-right every time.

Adjusting resolution etc has no effect.

---

@fcmonter commented on 2018-09-13T20:30:00

This bug is reported as present in My Summer Car #880 (which is a Unity game) - if you click a mouse button, or move the scroll wheel, your view shifts down-right every time.

Adjusting resolution etc has no effect.

You are right, I scrolled and clicked and it moved the camera, but even if i just move my mouse up it does the same thing as scrolling.

---

@fcmonter commented on 2018-09-13T20:30:24

Did you try to run Unity games in the native resolution of your display? That was a workaround for 831.

Yes, I have tried native full screen and various windowed resolutions.

---

@gbdlin commented on 2018-09-18T13:10:27

This is definitely a duplicate of #1418

[AmandaCameron]

I forgot to update this with a bit of info I discovered when trying @CrackedCrafterz's suggestion of windowed mode. Just before the giant jumps of the screen movement happen, the cursor flashes visiible, so I think it's got something to do with the mouse capture momentarially lapsing, at least for the large jumps in the view.

[Quinnux]

Is this just different ways of explaining things, or are there two different issues here? (I know a bunch of separate reports have just been merged together, but I'm not sure if they're all the same thing). Some of the other reports don't sound anything like the issues I was having.

To me, it sounds like we've got
i) Mouse drifts gently to the down-right when pressing buttons or using the scroll wheel (though they also click and scroll the things they're meant to), but otherwise works properly - though in normal use it moves slightly faster down and right than up or left
and
ii) Mouse loses focus/capture and jumps huge amounts from one place to another, and clicking the mouse moves it randomly instead of clicking?

Of course they're all unity mouse issues, so perhaps the fix would be the same regardless?

[AmandaCameron]

Scrolling the mouse wheel inside the game also causes the view to slowly inch down-right as well, though I may have forgotten to mention that in my original issue.

…

On Tue, Sep 18, 2018 at 12:23 PM Quinnux ***@***.***> wrote: Is this just different ways of explaining things, or are there two different issues here? (I know a bunch of separate reports have just been merged together, but I'm not sure if they're all the same thing). Some of the other reports don't sound anything like the issues I was having. To me, it sounds like we've got i) Mouse drifts gently to the down-right when pressing buttons or using the scroll wheel (though they also click and scroll the things they're meant to), but otherwise works properly - though in normal use it moves *slightly* faster down and right than up or left and ii) Mouse loses focus/capture and jumps huge amounts from one place to another, and clicking the mouse moves it randomly instead of clicking? Of course they're all unity mouse issues, so perhaps the fix would be the same regardless? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1418 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG_zs2kqFPJuOfVKECH8C4xW5bCkfhBks5ucR4WgaJpZM4Wl_YR> .

[GrayHatter]

I also have this bug in stationeers on Arch Linux x64, running i3.

The bug seems to come from how [thing] keeps trying every [time] to re grab control of the mouse. Every time the mouse jumps, my window manager cursor turns into the default i3 arrow for a frame or two before turning back into what ever the game selected.

Could also be that when it does it's calculations as to where it should put the mouse, it's wrong. When I had my side monitor set as the default, and I forced the game into windowed mode from i3 (not from Stationeers), and put it on my main screen, it would jump the cursor over to the screen it opened on, not the actual screen the game was running on.

I'd start digging into the code and see if I can't fix the bug, but the repo source is just a mess I don't even know where to start looking for the cursor handling code...

[AmandaCameron]

I did some digging today, and some minor hacking on Proton, and I've discovered that the cursor appears to be appearing briefly because the capture is being released. I'm not entirely sure why, but this is what I got when I added a TRACE call to X11DRV_SetCapture:

13744.890:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13744.896:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to 0x1004a
13744.896:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13746.450:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13746.451:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to 0x1004a
13746.451:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13748.398:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13748.398:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to 0x1004a
13748.398:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13773.327:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13773.327:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to 0x1004a
13773.328:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13775.145:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)
13775.145:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to 0x1004a
13775.146:0008:0009:trace:x11drv:X11DRV_SetCapture setting capture to (nil)

EDIT: All of these go away if I move my TRACE below the flags check. I'm not sure what exactly would be calling XGrabPointer if not this or grab_clipping_window though, and I'm not seeing any output from grab_clipping_window, either.

[AmandaCameron]

I've made a patch which appears to have fixed the issue, at least on my machine, but only when the game is running in a window, and not full-screen.

The basic idea behind my patch was "It seems XInput2 and X11's normal mouse movements are conflicting with each other. Let's just use one or the other a a time."

I accomplished this by turning the ButtonPress/ButtonRelease/MotionNotify events into stubs while an active clip is going on, and the XInput2 event handlers take over completely. And similarly, while there's no clipping going on, the XInput2 event handlers are stubbed to allow the X.Org mouse input to take over.

It's not very eloquent, but it works well enough for my personal use.

The issue I found with using just XInput2 for movement is there's a noticeable drift from where X.Org thinks the cursor is, and where wine is pretending it is, which is the main mode of how the patch fails under full-screen.

[kisak-valve]

Hello @AmandaCameron, your patch should go to upstream wine.

[aufkrawall]

Like reported in #147 , the issue does not exist in wine-staging 3.15 (tested with The Forest). I don't know what exact commit fixed it there, but it would be nice if it could get merged into Proton.

Edit: I'm referring to the "mouse drift" issue.

[AmandaCameron]

I tested Stationeers on Wine 3.16 (through PlayOnLinux) so the issue at least exists in that version. Might be that whatever fixed it in staging didn't make it into production, or it might be that your DE doesn't cause the issue to manifest. It's been mentioned that it's not as bad in windowed mode, or under certine other DEs / WMs. I've not dug too far into the GNOME Shell code, but I suspect they're trying to be "helpful" in some way to synthesise additional MotionNotify events, which is causing the glitch in Wine. When I enabled the right WINEDEBUG + added some more TRACE's myself, it was clear that the jumps happen around when a MotionNotify event happen, and the MotionNotify events roughly lined up with the delta of the XIRawMotion events. I've updated my patch since the inital post in this thread, changing the XInput2 / X.Org events to be switched between based on the cursor's visibility. I'm currently trying to find some time to submit the patch upstream, to have it looked at by wine devs directly, but it's a bit hard to get moving on that front.

…

On Sun, Sep 30, 2018 at 6:18 AM aufkrawall ***@***.***> wrote: Like reported in #147 <#147> , the issue does not exist in wine-staging 3.15 (tested with The Forest). I don't know what exact commit fixed it there, but it would be nice if it could get merged into Proton. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1418 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG_zmXX6Rf8CQcCF63CwFfazetwmNllks5ugJpXgaJpZM4Wl_YR> .

[aufkrawall]

Issue does still persist with Proton 3.16-1. It would be nice if this could get some traction as it's a general issue which makes several games unplayable and is already fixed with wine-staging since 3.15.

[Drangleic]

Can confirm I’m seeing this in The Forest as well. I have to fight the mouse only when moving it up and left. It only happens when controlling the player character and when in the Survival Book. Mouse works normally in menus.

Also, I am using Proton 3.16-1

[dprien]

Related bug report for Wine

And this seems to be the wine-staging commit containing the fix.

[meowmeowfuzzyface]

This issue is present in Dusk as well. As far as I can tell, it's the only thing preventing the game from functioning perfectly.

[aufkrawall]

This issue is still not fixed in Proton 3.16-5 beta.

[ghost]

they just need to pull https://bugs.winehq.org/show_bug.cgi?id=42631

[im-0]

I am not sure that the problem with mouse in Subnautica and mouse-related problems in other Unity-based games are caused by the same bug.

Here is how it looks in stable Subnautica (Sep-2018 61056):

• There are two mouse "modes" in Subnautica: "cursor mode", which is active in inventory (Tab), craft menu (when you use some crafting device) or in the game menu (Esc); and "camera mode", which is active when you are controlling your character.
• Right after the beginning (new game or loaded game after restart) everything works almost fine. There are some problems with precision, but not that critical.
• After ~15 minutes of playing, "cursor mode" breaks: mouse cursor sticks to the center of the screen and can not be moved. "Camera mode" still works fine.
• Alt-Tab to the desktop while in "cursor mode" fixes this problem. But "camera mode" breaks: everything goes crazy and camera moves like mouse sensitivity increased x100.
• Another Alt-Tab when game is in "camera mode" fixes "camera mode", but breaks "cursor mode" again.
• You are forced to Atl-Tab continuously to unbreak your camera/inventory while the Reaper Leviathan tries to eat you =).

Patch from @AmandaCameron (#1418 (comment)) fixes this. After ~10 hours of testing, I've encountered only one problem with stuck cursor in "cursor mode" (maybe this happened because I tested this in fullscreen mode). Anyway, this patch finally makes Subnautica playable.

It is also possible to fix mouse problems by switching to the "experimental" builds of Subnautica in Steam, but experimental version have a lot of other bugs not related to Proton/Wine/Linux.

Versions:
Subnautica: Sep-2018 61056 (latest stable on steam)
Proton: b7d0a64 (manually built)
gnome-shell: 3.30.2 (under Xorg)
Xorg: 1.20.3

[im-0]

they just need to pull https://bugs.winehq.org/show_bug.cgi?id=42631

If you are talking about "winex11: Don't react to small slow mouse movements", it is already there: ValveSoftware/wine@7a0711b

And it does not help in the case of Subnautica.

[taisph]

The wine patch describes exactly what I'm seeing in Stationeers and it is still an issue with Proton 3.16-6 beta. Slow movement pulls mouse towards bottom right corner.

[imaami]

Proton 3.16-6 beta still has the bug where you have to "fight" the mouse when moving up and/or left. It becomes apparent in Tannenberg when aiming.

[aeikum]

The drift to bottom-right is fixed by this wine-staging patch: https://github.com/wine-staging/wine-staging/tree/master/patches/server-ClipCursor

We'll look at integrating it into Proton.

[aeikum]

The patch was accepted into Wine and will make its way into Proton soon. https://source.winehq.org/git/wine.git/commitdiff/5ff6a116972089f8e112dd4234d57689a60ab4dc

[Managor]

Yep. It's fixed on proton now. Tried with My Summer Car and the mouse no longer drifts.

[ghost]

Yep The forest works now out of the box too :)

[taisph]

Subnautica mouse problems as described in #1418 (comment) are still present in 4.2-2.

[phrogg]

also still present in 4.2-5 is the mouse jumping in car mechanic simulator 2018.

[bastimeyer]

The auto-moving cursor seems to be fixed now in 4.11-1, tested in Subnautica.
The mouse lock issue unfortunately has not been fixed.

[LtSich]

Recently Stationeers have updated the Unity Engine.
And now when I clic on the mouse button the camera jump to watch my feet...

If you want to play you have to reconfigure your keys to use something else that the mouse button...

This bug was not present in the last release before the unity engine update.

ATM I didn't receive any answer on the Stationeers forum...
But I have tested with different version of Proton and the previous version of the game.
The problem is only here with the last version who use a new version of unity.

I don't have more information about that...

[sPrinGfieldd]

LtSich I noticed the same thing in Stationeers today. This seems to be screwed again.

[TaiTair]

Yup Stationeers is still broken. Mouse clicks make the camera focus on the ground. Proton 4.11-6 here.

[LtSich]

Yep, 4.11-6 doesn't solve the problem :(
Sadly :(

[phrogg]

Problem for car mechanic also persist.

[passionateengineer]

I noticed exactly the same problem as LtSich did. Before the unity engine update stationeers worked fine but now the character is turning away if I click a mouse button.

[LtSich]

The problem still exist :(
Anyone have any news about that ?

On unity side ? Or on Proton side ?

[LtSich]

The last proton version 4.11-10, or the last update from the game have fixed the issu with the mouse !
I don't know wich update have fixed that (game or proton), but at least now it's working again for me on Stationeers :)

[passionateengineer]

With proton version 4.11-10 its working for me too. Thanks Proton!

[taisph]

I can confirm that Stationeers is finally playable again with 4.11-10. Got 4 hours in yesterday.

[phrogg]

I can also confirm Car Mechanic Simulator 2018 does work now aswell.

[kisak-valve]

Closing as fixed in Proton 4.11-10.