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.