http://bugs.winehq.org/show_bug.cgi?id=32840
Bug #: 32840 Summary: Mouse input regression caused by changes in GetTickCount64 Product: Wine Version: unspecified Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-dinput AssignedTo: wine-bugs@winehq.org ReportedBy: jimportal@gmail.com Classification: Unclassified
Since fa9a883dbbd49117c2e53f5b3ea8cd49397bf520 (kernel32: Use the monotonic counter in GetTickCount64.), mouse input behaves erratically in World of Warcraft when using the mouse to turn or change camera view angle. The mouse behaves fine when the mouse cursor is displayed for clicking buttons.
This also causes problems in Prey and Painkiller.
http://bugs.winehq.org/show_bug.cgi?id=32840
James Eder jimportal@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Regression SHA1| |fa9a883dbbd49117c2e53f5b3ea | |8cd49397bf520
http://bugs.winehq.org/show_bug.cgi?id=32840
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #1 from Austin English austinenglish@gmail.com 2013-01-29 14:32:22 CST --- *** Bug 32841 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=32840
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|directx-dinput |-unknown
http://bugs.winehq.org/show_bug.cgi?id=32840
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.5.22
http://bugs.winehq.org/show_bug.cgi?id=32840
Jeff Cook jeff@deserettechnology.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff@deserettechnology.com
--- Comment #2 from Jeff Cook jeff@deserettechnology.com 2013-01-30 00:37:57 CST --- FYI reversion of 199c99d852d2db635bbc8d41986d971551ca7d72 is necessary to revert fa9a883dbbd49117c2e53f5b3ea8cd49397bf520 after today's changes on git.
This also affects Skyrim.
http://bugs.winehq.org/show_bug.cgi?id=32840
--- Comment #3 from Jeff Cook jeff@deserettechnology.com 2013-01-30 13:53:10 CST --- We had some adventures with this in #winehackers early this morning.
It seems the likely cause is that something is using get_tick_count() in server/request.c or a similar function that would have a large variance from the system-provided monotonic timer, which will typically reflect the given uptime of the machine in milliseconds regardless of when the wine server starts, and that somewhere a comparison is occurring that causes an underflow or something.
We haven't been able to pinpoint the cause of mouse inversion in some menus, but investigation appears to clear user32/input.c (though there is a bug here where the hardcoded 100ms server update interval is useless with the monotonic timer because the difference from last_change, which is a low number, is always going to be much higher than 100; practically, the only effect of this bug is probably some wasted CPU cycles) and similar obvious mouse-related suspects.
Did some light tinkering with pdh.dll but I don't think there's anything really there. GetTickCount64 is rarely called directly, but its output is fed to GetTickCount, which then gets cast/truncated into a DWORD.
Still not much of a clue as to why axes are getting inverted, but it definitely seems the transition to monotonic GetTickCount*() functionality hasn't been thoroughly tested. It appears there are several places where the comparison of monotonic and non-monotonic timers, while theoretically not necessarily problematic, may result in conflicts or unexpected behavior, which may or may not manifest in applications as bugs (and in this case, obviously one does). I almost want to suggest that the change gets rolled back if these can't all be ferreted out and we can't confirm that every comparison is from the same type of timer, or that in cases where timers with different originations are compared, we ensure there is no potential issue.
http://bugs.winehq.org/show_bug.cgi?id=32840
--- Comment #4 from Jeff Cook jeff@deserettechnology.com 2013-01-30 14:06:56 CST --- Fixed by today's git commit:
commit a74dc1a1195b38e0e04798799229a3aab8a021ef Author: Alexandre Julliard julliard@winehq.org Date: Wed Jan 30 12:49:33 2013 +0100
server: Use the monotonic time counter also on the server side.
This seems to address the server side time discrepancy, though I would still encourage thorough auditing because mouse axes shouldn't invert even if there is a large discrepancy in timer origination points (both timers still kept accurate times). There is likely still an underflow somewhere.
http://bugs.winehq.org/show_bug.cgi?id=32840
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |a74dc1a1195b38e0e0479879922 | |9a3aab8a021ef Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com 2013-01-30 14:07:50 CST --- Fixed with a74dc1a1195b38e0e04798799229a3aab8a021ef.
http://bugs.winehq.org/show_bug.cgi?id=32840
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #6 from Alexandre Julliard julliard@winehq.org 2013-02-01 04:57:49 CST --- Closing bugs fixed in 1.5.23.
https://bugs.winehq.org/show_bug.cgi?id=32840
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |focht@gmx.net Component|-unknown |wineserver
-
wine-bugs＠winehq.org