https://bugs.winehq.org/show_bug.cgi?id=38420
Bug ID: 38420 Summary: Sticky mouse with xinput2 Product: Wine Version: 1.7.39 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput Assignee: wine-bugs@winehq.org Reporter: brebs@sent.com Distribution: ---
Hi, the Stalker series and also Sniper Elite have been affected by this issue for years, since the infamous Wine "mousewarp" bugs.
When wine (currently tried upto 1.7.39) is *not* compiled with the option:
--without-xinput2
Then the full-screen mouse has a strange intermittent sticky/slowdown effect, on both horizontal and vertical axes. It seems like xinput2's pointer barriers are taking effect - the mouse gets some invisible resistance, and has to be "pushed through" the barrier with extra force.
This is only an issue when wine is compiled *with* xinput2.
This is especially a problem with the Stalker games (e.g. Stalker Lost Alpha), which need the mouse to work in the menu & inventory screens, as well as first-person view.
https://bugs.winehq.org/show_bug.cgi?id=38420
Paul Bredbury brebs@sent.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |brebs@sent.com
--- Comment #1 from Paul Bredbury brebs@sent.com --- Created attachment 51274 --> https://bugs.winehq.org/attachment.cgi?id=51274 Fixes mouse in Stalker
This patch adds the "force_edge" MWO option, which makes the mouse in Stalker work reasonably, when Wine is compiled using the option:
--without-xinput2
https://bugs.winehq.org/show_bug.cgi?id=38420
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
--- Comment #2 from Robert Walker bob.mt.wya@gmail.com --- Paul could you describe the symptoms of the problem in a bit more detail? If you could I can build Wine with and without the patch easily enough (since I use Gentoo on my desktop rig) to confirm the issue. To be able to replicate the issue I need to know if it's easily triggered by any particular (in-game or menu) actions - or whether it's totally an intermediate issue! Thanks.
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #3 from Paul Bredbury brebs@sent.com --- The quickest way to see the problem, in Stalker first-person view, is to continually, slowly move the mouse in 1 direction horizontally. After turning 180 degrees (IIRC - might be 360), the first "stickiness" (pointer barrier?) appears, whereby the mouse movement slows down, as if it's hitting some resistance. After that, if you keep turning in the same direction, there's a succession of barriers.
If you move the mouse *quickly*, then the barrier is hardly noticeable. To see the problem, move the mouse fairly slowly.
The barriers are always present - e.g., turn 180 or 360 degrees in the opposite direction, to hit another area of mouse stickiness.
https://bugs.winehq.org/show_bug.cgi?id=38420
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #4 from Robert Walker bob.mt.wya@gmail.com --- (In reply to Paul Bredbury from comment #3)
The quickest way to see the problem, in Stalker first-person view, is to continually, slowly move the mouse in 1 direction horizontally. After turning 180 degrees (IIRC - might be 360), the first "stickiness" (pointer barrier?) appears, whereby the mouse movement slows down, as if it's hitting some resistance. After that, if you keep turning in the same direction, there's a succession of barriers.
If you move the mouse *quickly*, then the barrier is hardly noticeable. To see the problem, move the mouse fairly slowly.
The barriers are always present - e.g., turn 180 or 360 degrees in the opposite direction, to hit another area of mouse stickiness.
Paul I simply can't replicate this issue here. I removed the staging patches I had applied and re-tested. Still no sign of this issue. I also checked out Bioshock and S.T.A.L.K.E.R.: Shadow of Chenobyl. Sorry just can't replicate it.
https://bugs.winehq.org/show_bug.cgi?id=38420
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #5 from super_man@post.com --- Paul are you still experiencing this bug? There was a recent commit that fixed mouse movement regression in wine. I don't remember the exact wine version it was included but you should be safe if you have 1.7.55 or newer.
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #6 from Paul Bredbury brebs@sent.com --- Yes, this is still a problem. Move the mouse *slowly* to the right through 180 degrees, and there is a weird, invisible, resistance barrier which requires a bit more momentum to *punch* through, to be able to continue moving to the right.
Tested in Sniper: Elite, in Wine versions: 1.7.54 1.7.55 (with wine-staging patches) 1.8-rc1
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #7 from Paul Bredbury brebs@sent.com --- Same problem in Far Cry 3, with wine 1.9.23
The fix for me is to compile wine --without-xinput2, add the patch from comment #1, and run:
wine reg add 'HKCU\Software\Wine\DirectInput' /v MouseWarpOverride /d force_edge
https://bugs.winehq.org/show_bug.cgi?id=38420
Peter Kruczkiewicz peter.kruczkiewicz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |peter.kruczkiewicz@gmail.co | |m
--- Comment #8 from Peter Kruczkiewicz peter.kruczkiewicz@gmail.com --- Hi, I have encountered the same issue as described by Paul with STALKER Call of Pripyat/Call of Chernobyl/Call of Misery.
Compiling wine with --without-xinput2 and applying the patch to mouse.c (https://bugs.winehq.org/attachment.cgi?id=51274) seems to fix the mouse stickiness in game. However, I am running a dual monitor setup and the mouse cursor escapes the game window. The mouse escape issue is solved with disabling one of the monitors when playing the game.
Thank you Paul for the fix!
https://bugs.winehq.org/show_bug.cgi?id=38420
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=38420
Alistair Leslie-Hughes leslie_alistair@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=38420
joaopa jeremielapuree@yahoo.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeremielapuree@yahoo.fr
--- Comment #9 from joaopa jeremielapuree@yahoo.fr --- Does the bug still occur with wine-5.18?
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #10 from joaopa jeremielapuree@yahoo.fr --- No news from the reporter since 6 years. No download available. Can an administrator close this bug as ABANDONED?
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #11 from Paul Bredbury brebs@sent.com --- Hi, I've just tried this in Void Linux with Void's vanilla Wine 6.20 package ( https://github.com/void-linux/void-packages/tree/master/srcpkgs/wine ), and the issue still exists.
It's subtle, but certainly present - the mouse must be moved *slowly* in one direction (left or right are the easiest directions to test) for a while, and then it starts moving at about a third of its expected pace, whereas moving it in the opposite direction again is full-speed.
https://bugs.winehq.org/show_bug.cgi?id=38420
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #12 from Rémi Bernon rbernon@codeweavers.com --- There's perhaps several things into play here as I can see that there's a patch changing something in DInput, but as far as I know vanilla Wine suffers from a well understood bug from XInput raw values, where the mouse movement may contain sub-pixel values which is truncated in winex11.drv.
There's several patches laying around to fix this, one in Wine Staging (user32-rawinput-mouse-experimental/0003-winex11.drv-Accumulate-mouse-movement-to-avoid-round.patch), but they have some dependencies on other rawinput related patches which aren't going to be upstreamable easily (many other things need fixing first).
I'll try to have a look at some point, see if it could be rebased the other way around and have the sub-pixel patches upstreamed first.
It would be awesome if someone could confirm that this Wine Staging patch series fixes the problem reported here as I believe it does.
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #13 from Paul Bredbury brebs@sent.com --- Hi, the lutris-6.0 version of Wine ( https://github.com/lutris/wine/tree/lutris-6.0 ), which seems to include wine-staging, does not have this problem - it seems like different mouse-handling code is involved, because the mouse is also faster and feels smoother.
https://bugs.winehq.org/show_bug.cgi?id=38420
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=42631
https://bugs.winehq.org/show_bug.cgi?id=38420
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |f7ac9f309f2964e131c8e60c5ff | |3a878b67b2e32 Status|UNCONFIRMED |RESOLVED
--- Comment #14 from Rémi Bernon rbernon@codeweavers.com --- I think it should be fixed with f7ac9f309f2964e131c8e60c5ff3a878b67b2e32, please reopen if it's not.
https://bugs.winehq.org/show_bug.cgi?id=38420
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 6.21.
https://bugs.winehq.org/show_bug.cgi?id=38420
--- Comment #16 from Paul Bredbury brebs@sent.com --- Hi, just to confirm, this is fixed in Wine 6.21, thanks.
-
wine-bugs＠winehq.org -
WineHQ Bugzilla