https://bugs.winehq.org/show_bug.cgi?id=43918
Bug ID: 43918 Summary: Crysis 3: Mouse movement unreliable,mouse cursor jumps around Product: Wine-staging Version: 2.19 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: christian.frank@gmx.de CC: erich.e.hoover@wine-staging.com, michael@fds-team.de, sebastian@fds-team.de Distribution: ---
Hi,
i managed now to get into the crysis 3 campaign. I now noticed that the mouse is not usable in game. It is jumping around etc. I also had that issue in the menu after disabling vsync. Enabling vsync fixed in the menu, but not in game.
Which logs are needed ?
I am not sure if that issues also happens in usual wine but i fear crysis 3 will not go into campaign with normal wine.
Thanks !
https://bugs.winehq.org/show_bug.cgi?id=43918
--- Comment #1 from Christian christian.frank@gmx.de --- I forgot to add my system specs:
Opensuse Tumbleweed Geforce GTX970 with latest stable Nvidia driver XOrg environment, no wayland
https://bugs.winehq.org/show_bug.cgi?id=43918
Christian christian.frank@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|2.19 |3.3
--- Comment #2 from Christian christian.frank@gmx.de --- Hi,
thats still in issue in wine-staging 3.3 . I can not test with normal wine cause Origin does not work with it.
As soon as you move the mouse it is jumping around, going crazy.
Which traces would be interesting ?
Many thanks ! Christian
https://bugs.winehq.org/show_bug.cgi?id=43918
tokktokk fdsfgs@krutt.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs@krutt.org
https://bugs.winehq.org/show_bug.cgi?id=43918
Christian christian.frank@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|3.3 |3.5
--- Comment #3 from Christian christian.frank@gmx.de --- Hi,
that is still an issue in wine-staging 3.5 but it is NOT an issue in wine 3.5 . So this is a wine-staging specific bug.
Best regards Christian
https://bugs.winehq.org/show_bug.cgi?id=43918
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #4 from Zebediah Figura z.figura12@gmail.com --- Thanks for the bug report. Would it be possible for you to perform a regression test to determine which Staging patch causes the bug? It'll be a little trickier than normal since you'll have to remember to rerun autoconf -f and ./tools/make_requests at every iteration.
You might also try checking the dinput patches to see if they're the culprit—if one of them is, that would save the effort.
https://bugs.winehq.org/show_bug.cgi?id=43918
--- Comment #5 from Michael Müller michael@fds-team.de --- (In reply to Zebediah Figura from comment #4)
Thanks for the bug report. Would it be possible for you to perform a regression test to determine which Staging patch causes the bug? It'll be a little trickier than normal since you'll have to remember to rerun autoconf -f and ./tools/make_requests at every iteration.
Or you simply apply the patches using patchinstall.sh --all --backend=git-am --force-autoconf and the script will add the auto-generated changes to each commit. Then you can do normal regression test.
https://bugs.winehq.org/show_bug.cgi?id=43918
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- (In reply to Michael Müller from comment #5)
(In reply to Zebediah Figura from comment #4)
Thanks for the bug report. Would it be possible for you to perform a regression test to determine which Staging patch causes the bug? It'll be a little trickier than normal since you'll have to remember to rerun autoconf -f and ./tools/make_requests at every iteration.
Or you simply apply the patches using patchinstall.sh --all --backend=git-am --force-autoconf and the script will add the auto-generated changes to each commit. Then you can do normal regression test.
Ah, thanks; I wasn't aware of that option.
https://bugs.winehq.org/show_bug.cgi?id=43918
Béla Gyebrószki gyebro69@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gyebro69@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=43918
--- Comment #7 from Christian christian.frank@gmx.de --- Hi,
I think we can close this bug, as it is fixed. Mouse works fine in Crysis 3 also in staging.
Many thanks ! Christian
https://bugs.winehq.org/show_bug.cgi?id=43918
zzzzzyzz@hacari.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zzzzzyzz@hacari.org
https://bugs.winehq.org/show_bug.cgi?id=43918
bocadillodeatun fernando@gluegarage.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |fernando@gluegarage.com
--- Comment #8 from bocadillodeatun fernando@gluegarage.com --- Are you sure this is fixed?
I'm using 3.14-staging and the problem still happens.
In particular, depending on the set of options used to configure wine before running the game, the behavior changes in the following ways:
XORG: 1.20.1 WINE: 3.14-staging DXVK: 0.70
CONFIGURATION SETTINGS | RESULT ---------------------------------------------|------------------------------ # Virtual Mouse warp Capture In-game | Mouse Mouse desktop override mouse graphics | in menus in game ============================================================================ 01 yes enable no windowed | ok crazy 02 yes enable no fullscreen | ok box limited 03 yes enable yes windowed | ok crazy 04 yes enable yes fullscreen | ok crazy | 05 yes force no windowed | fixed box limited + jitter 06 yes force no fullscreen | fixed ok 07 yes force yes windowed | fixed box limited + jitter 08 yes force yes fullscreen | fixed crazy | 09 no enable no windowed | ok crazy 10 no enable no fullscreen | ok crazy 11 no enable yes windowed | ok crazy 12 no enable yes fullscreen | ok crazy | 13 no force no windowed | fixed box limited + jitter 14 no force no fullscreen | fixed box limited + jitter 15 no force yes windowed | fixed box limited + jitter 16 no force yes fullscreen | fixed box limited + jitter
Now... a few notes:
* The "capture mouse" setting is what you can find under in the "wine configuration" tool under the "Graphics" tab: "Automatically capture the mouse in full-screen windows"
* When I say the mouse is "fixed" it means you can try to move it, and it does, but it will then immediately return to the center of the screen (thus rendering menus unusable using the mouse)
* "Box limited" is the same behavior reported in this other ticket: https://bugs.winehq.org/show_bug.cgi?id=43624 ie. you can move the mouse but up until certain point (ex: you can only rotate +/- 45 degrees approx.)
* "Crazy" probably means the same behavior originally reported on this ticket: if you move the mouse really slowly it works, but as soon as you make a quick turn, the amount of movement seems to "accumulate" and the mouse starts doing crazy jumps.
* "Box limited + jitter" is a combination of the previous two cases: as long as you remain "inside of the box" everything works, but when you "touch an edge", the "crazy mode" turns on.
Right now I can play the game using setting (06), I just need to use the keyboard to navigate the menu.
https://bugs.winehq.org/show_bug.cgi?id=43918
--- Comment #9 from bocadillodeatun fernando@gluegarage.com --- In the previous comment I explained how the following configuration (number #06) is the only one that works for me:
CONFIGURATION SETTINGS | RESULT ---------------------------------------------|------------------------------ # Virtual Mouse warp Capture In-game | Mouse Mouse desktop override mouse graphics | in menus in game ============================================================================ 06 yes force no fullscreen | fixed ok
With these settings at least I can play the game, but I cannot use the menus with the mouse (I must use the keyboard instead, but that's ok).
Anyway, trying to figure out what is going on with the mouse in the menus, I enabled the "dinput" channel logs on this particular scenario and noticed how the following message was been constantly generated:
"warp_check Warping mouse to 960 - 540"
This message is being printed from the following piece of code:
function mouse.c:warp_check() =============================
1 if (!This->clipped) 2 { 3 mapped_center.x = (rect.left + rect.right) / 2; 4 mapped_center.y = (rect.top + rect.bottom) / 2; 5 TRACE("Warping mouse to %d - %d\n", mapped_center.x, mapped_center.y); 6 SetCursorPos( mapped_center.x, mapped_center.y ); 7 }
I have *no idea* about the wine code (this is the first time I have a look at it)... but I tried to comment out line 6, and two things happened:
1. Unsurprisingly, the mouse in the menus now works (great!)
2. BUT... surprisingly, the mouse in the game no longer warps and its movement is limited to a virtual box (what I called "box limited" in the previous comment)
So... the "reset" of the mouse position back to the center of the screen is somehow needed by the warping mechanism. It's just that we need to tell apart between the two possible scenarios ("menus" and "in-game") to decide whether the mouse position must be reset or not.
In other words, we need to add a condition here:
1 if (!This->clipped) && some_new_condition 2 { ------------------ ... ^ 7 } here
If anyone knows what that condition might be, I can try it... in the mean time I'll keep looking at the code.
-
wine-bugs＠winehq.org