Some one few weeks ago mentioned that they needed SetCursorPos to work globally (between processes). Well it seems after all we do need that to fix few lots of things, including most mouse related bugs in dinput.
Actually the problem I have is not as much with SetCursorPos as with the fact that with multiple processes only one gets MotionNotify (and other notify) events. This gets cursor position out of sync between two processes and causes interesting side-effects. It's not something major but an annoyance. There are could be more serious problems however.
The possible solutions might be: 1. Store cursor_pos in wineserver and call wineserver whenever we need it or need to modify it. Seems straight forward but how expensive it would be? 2. Use shared memory. That means we have to allocate it first (will SharedUserData work for this?). And use mutex for sync. 3. Query X for it's cursor position. Pretty much what we do, except that needs to be fixed:
Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X.
Any ideas appreciated.
Vitaliy
Vitaliy Margolen wine-devel@kievinfo.com writes:
Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X.
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 we won't receive events from other processes anyway. Now it probably doesn't need to update cursor_pos asynchronously, we could wait for the X events to do that; but I'm not sure if that would help with your problem.
Monday, August 7, 2006, 1:28:45 PM, Alexandre Julliard wrote:
Vitaliy Margolen wine-devel@kievinfo.com writes:
Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X.
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.
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.
doesn't need to update cursor_pos asynchronously, we could wait for the X events to do that; but I'm not sure if that would help with your problem.
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.
I'm trying to get our cursor behaving the same way as native does. Otherwise there always will be this one app that does things differently...
Vitaliy
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?
Tuesday, August 8, 2006, 1:48:51 AM, Alexandre Julliard wrote:
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).
Ah you mean Wine's message queue? I thought we get X's notifies via direct callback. Is this not the case then?
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.
Well app shouldn't really need to know if cursor is outside it's window. And since we won't be generating WM_* messages in such case why even bother? Or... we can do something what native does - spurious WM_MOUSEMOVE messages (well known ... feature it seems) that probably come from querying mouse on some interval.
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?
Attached. Small test and patch to fix it (against current git).
Vitaliy
-
Alexandre Julliard -
Vitaliy Margolen