When the mouse is outside one of our windows, we don't send motion events back to the server. This can cause some applications to mistakenly think that we're still where we were when we moved away, on or at the edge of the window, causing them to display tooltips or other context sensitive widgets. (worse if the application window is programmatically enlarged to include this point) Other applications simply don't work, ie: xeyes.
The solution is to simply poll the mouse (at a slower rate) when we're outside the windows. Patch that does this attached to the ticket.
Remaining issues:
mouse position synchronization via polling
Merged with minor changes in r8415, with the new command line option mouse-polling which defaults to 0.25s. We can also use this setting to disable the feature if it causes problems. Synergy does not seem to be causing a problem: this is just another fullscreen window as far as we are concerned, our windows aren't raised by these motion events, so they aren't firing hover events or anything.
Since we also synchronize modifiers state, this change should also help with:
afarr: this is just FYI, please close. (though if you want to test more on OSX, I won't stop you..)
r8467 is a fix for a bug made more apparent by this change (backport in r8470), see also #759
Other mouse position related changes worth mentioning here: r8482 (direct X11 calls replace GTK calls)
Undone in r8499: it just cannot be done well.
When applications have tooltips, we end up triggering those tooltips (which can really cause problems, made worse by #761). There is no API for figuring out which window is at a specific location, so we can't decide whether it is safe to move the pointer there. (and even then, this would be very hackish and confusing)
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/780