I hit the same issue with wine-staging 3.13.1. It's a long standing wine bug.

I had the same problem when I was playing DOOM through wine, in my case this was connected to the wayland session.

Does the problem still exist when using the Xorg session ? (assumeing you are running a recent version of gnome3 or plasma 5 wayland session)

@elovin yes it's present on Xorg as well.

Same problem here on RedHat 7.5 playing Quake 3

Happens to me as well on several games. Battlefront 2, Worms (DOSBox), Ultimate DOOM, Tomb Raider 1 (DOSBox) to name a few.

X11 session
Ubuntu 18.04.1 LTS
Proton 3.7 with default settings

Try turning your report/polling rate down to 125

I hit this issue in Doom as well with my g502, and when I moved the mouse slowly in one direction it felt like it "hit the edge of the screen" and stop moving completely. Swapped to a different mouse and the issue went away, figured it was my mouse settings, and dropped the report rate to 125 and that fixed the issue.

That makes sense. I'm having the same issue with DOOM under Proton, but I have noticed the same problem previously with other games in Wine. I first noticed the issue after I bought a new gaming mouse (Roccat Kone Aimo).

Unfortunately I am not able to change the mouse polling rate. I tried following the instructions on the Arch Wiki but they have no effect. It stays at 1000 hz.

@unlimitedbacon Have you tried using roccat-tools or roccat-tools-kone from the AUR?

I had to change the settings on a Windows machine and save to the mouse on-board memory. You might be able to get away with running the roccat software in WINE or do a USB passthrough to a Windows VM?

Thanks, I was able to boot into Windows and use the Roccat tool to reduce the polling rate. The problem is still definitely happening, however it is reduced enough that the game is playable.

The mouse only gets stuck when you are moving it very slowly. If you are making quick precise moves it is not a problem, but if you are making subtle movements it makes it hard to aim accurately.

I also have a mouse with 1000Hz pooling rate A4Tech X7 and I see this is also discussed here:
https://steamcommunity.com/app/221410/discussions/0/490121928343092592/

If this happends also on native game this means it's a linux bug I guess. Does anyone know if a bug report already exists for this?

I never noticed this on any native game, so i definitly think this is a wine bug. Also i am on Xorg with nvidia driver (GTX 1050 Ti), so no Wayland issue.

But good to see others have the same problem. I played through the whole game once with this bug and never heard about someone with the same problem.

I will change my mouse polling rate just to test if its better, but definitly will set it back to 1000Hz after that.

So i did some testing and the issue seems definitly been tied to mouse polling rate.

At 125Hz and 500Hz there is no mouse lags of any kind for me. Neither when moving the mouse slowly nor very fast. Only at 1000Hz the issue is back. So i will just leave it at 500Hz for now.

Can confirm it's a 1000Hz issue, I'm using a Logitech g502 as well.

I'm experiencing the same issue on Ubuntu 18.04.1 LTS. Additionally I can't lower my mouse polling rate as described in the arch wiki: https://wiki.archlinux.org/index.php/Mouse_polling_rate#Polling_rate_not_changing

I can't move the mouse at all in DOOM. it's stuck in the top-left corner. I can move around the menu's with the keyboard, but once I launch a game the keyboard doesn't work either

I also cannot move the cursor in DOOM. When I launch a game the keyboard also doesn't work (I can't enter the level with [SPACE]). I have a Logitech g403 at 500Hz.

EDIT: also tried it with a 125hz mouse and removed all xorg.conf mouse config, still the same results

Then its probably another issue and not related to the 1000Hz problem.

Is any of you having the mouse wall issue using gnome-shell?

Yes using Gnome on Arch Linux.

Are you guys running dual or triple monitors? Because my theory is that that the invisible mouse cursor is not locked to the center of the screen while playing, and it's wandering around all screens until it hits the very edge of the left/rightmost monitor, which is when the camera movement gets stuck. Lowering the mouse report rate just makes it less frequent. Any toughts?

I typically run with dual monitors but I have also tested with the second monitor disabled. The problem still happens. It's definitely not hitting a screen edge since you can move the mouse faster and it will start moving again.

Also running Gnome, and no I'm running one monitor and the issue is present.

If you switch to another virtual desktop and then back, the cursor might stay visible, and it appears that the mouse hits the wall just as the cursor hits the edge of the screen. It might be that Wine fails to lock the cursor in place, but still gets relative move events.

I've seen this issue in skyrim (standard) and borderlands - it's not game specific and it looks to be a wine (and hence proton) bug. Can confirm that the mouse pointer is not being locked to the center of the screen properly - thus when you move the mouse enough in one direction to put it on the edge of the screen then what you observe is that slow mouse movements are practically ignored indefinitely if you keep moving in that direction. If you move the mouse in the opposite direction, then slow mouse movements are fine until the cursor reaches "the end" of the screen on that side - in which case you end up with the same situation as above

edit: here's the same issue mentioned on reddit (https://www.reddit.com/r/linux_gaming/comments/9893js/wine_games_not_capturing_mouse_properly/)

I've tested the 3.7.5-beta and the enabling of "Automatically capture mouse in fullscreen windows is enabled by default." does not fix the issue. The cursor is just not being reset to the center of the screen

On GTA V, "DirectInput" and "Raw" input modes exhibit this problem, but the "Windows" method works fine.

Could you guys give wine-staging 3.15 a try? It fixed The Forest for me, seems to work now without issues with 1000Hz polling rate at the same time.

That wine-staging Winex11 fix should really get merged into Proton.

I can confirm that the mouse works perfectly in GTA V with all input modes using wine-staging 3.15. Please merge the fix!

I have tried staging-3.15 + 1000hz mouse on games where I previously experienced the mouse issue, and it does seem to be fixed.

I tested Hitman (2016 DXVK) and Doom as well, the issue is also gone for me in these games.

Another Logitech G502 user with same issue, cursor won't move in game when slowly moving the mouse but fast rapid mouse movement works fine.

Game issue - The witness
Tested with Proton 3.7-6 Beta

Steam controller with mouse emulation works perfect and Logitech M310t works fine.

Would love to see this issue fixed!

I don't think it's been posted on this issue so far, so for reference, this is the corresponding wine bug thread and this is the patch that addresses the issue.

I have the same "mouse wall" or cursor lag issue with various games (GTA3 (12100), GTA-VC (12110), Q3A (2200), etc) with a Logitech M280 on SteamOS brewmaster (gnome3 desktop)

@Plagman @aeikum any progress on this?

@libcg Yes, it's on our radar.

Can confirm its resolved for me with Proton 3.7-7 Beta. Back at 1000Hz now. Thanks!

Issue fixed for me as well.

Thanks all for reporting and retesting.

Issue is not fully fixed in Proton 3.7-7 and The Forest, moving the mouse on the x axis makes it move down the y axis at the same time, or in other words: You always start looking down at the bottom when moving the mouse.

This is not the case with wine-staging 3.15, where mouse control in The Forst works perfectly fine.

This issue is fixed but in some game mouse 'drift' is still a problem. This fixed the 1000hz problem in the witness and subnautica but subnautica has mouse 'drift' to down-right of the screen when moving the mouse, clicking mouse buttons or scrolling with the mouse wheel.

Same issue with My Summer car [#880](https://github.com/ValveSoftware/Proton/issues/880)

Might wanna start another issue?

Not fixed for me with the default SteamPlay Proton version (3.16-9). As soon as I move my mouse with the polling rate set to 1000 Hz, I get heavy microstuttering.

I reduced the polling rate of my mouse to 250 Hz and the issue is gone.

It is not fixed for me either, I tried all available proton version on steam.
For me (on a Quadro RTX 3000, i7-10875H) if I move the mouse everything gets unuseably stuttery (even in the menu). A litle while after the last mouse input I can move around with the keys and navigate the menu fine. But the mouse input is unusable, same for PS4 controller.

And since I have the xhci-hcd module, accoring to the Arch wiki I cannot even change my polling rate.

Please reopen @aeikum.

And since I have the xhci-hcd module, accoring to the Arch wiki I cannot even change my polling rate.

I had the same issue, and I managed to work around it by changing the polling rate in the mouse itself. For my mouse (Steelseries Rival 300), this tool called rivalcfg could do that. You might be able to do the same thing for your mouse.

And since I have the xhci-hcd module, accoring to the Arch wiki I cannot even change my polling rate.

I had the same issue, and I managed to work around it by changing the polling rate in the mouse itself. For my mouse (Steelseries Rival 300), this tool called rivalcfg could do that. You might be able to do the same thing for your mouse.

Interesting, thanks for that. I have a Logitech g302 and don't know of any software on linux for it. I tried piper but it only allows to switch between 500 and 1000Hz and doesn't work anyway :)