xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 7 years ago

Closed 7 years ago

Last modified 12 months ago

#780 closed enhancement (wontfix)

improved mouse position synchronization

Reported by: Antoine Martin Owned by: alas
Priority: minor Milestone: 0.15
Component: core Version: trunk
Keywords: Cc:


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:

  • should this be a configuration option - some users may not want the server to know what they are doing with their mouse outside the xpra window
  • with synergy installed, I get nonsensical coordinates when the mouse is on the other computer - which could actually make things worse
  • assuming we can get the list of modifiers reliably, should we synchronize them?
  • if the position has not changed, should we even send anything?

Attachments (1)

mouse-position-sync.patch (2.9 KB) - added by Antoine Martin 7 years ago.
mouse position synchronization via polling

Download all attachments as: .zip

Change History (5)

Changed 7 years ago by Antoine Martin

Attachment: mouse-position-sync.patch added

mouse position synchronization via polling

comment:1 Changed 7 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas

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:

  • the keyboard state will be more consistent: we'll press / unpress modifiers sooner rather than having to wait for the mouse to hover over one of our windows
  • this may help with keyboard layout switching events - since we will forward the key events whether we're focused or not

afarr: this is just FYI, please close. (though if you want to test more on OSX, I won't stop you..)

comment:2 Changed 7 years ago by Antoine Martin

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)

Last edited 7 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 7 years ago by Antoine Martin

Resolution: wontfix
Status: newclosed

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)

comment:4 Changed 12 months ago by migration script

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/780

Note: See TracTickets for help on using tickets.