Vitaliy Margolen wine-devel@kievinfo.com writes:
GetCursorPos really needs to query X, because there's no guarantee that the app is processing X events, and even if we hack around that
What do you mean here? X will always send notifies to a window (or am I wrong here?) And in notify handler we pretty much setting the cursor_pos.
But that requires that we pull events from the queue, and GetCursorPos() doesn't do that (and can't since we don't want to generate repaints etc. in there).
we won't receive events from other processes anyway. Now it probably
That's the thing. We either need to send mouse notifications to all processes (via wineserver?) or don't really need them, as long as we can synch cursor_pos between processes.
That doesn't help, the other process is not necessarily a Wine process.
Not so. According to few tests native always sets cursor_pos (what ever it's called internally - I'll call it that ;-) in SetCursorPos(). But on mouse moves it's not being set immediately but after calling hooks and generating WM_ messages. And that's the part lots of games relay on, including native dinput.
Any chance you could write a small test case that replicates the behavior you have observed?