games rely on precise mouse movements and their timing

[Antoine Martin]

effectively, they do their own mouse acceleration, and since we send the mouse movements packets when we feel like it, the games see jerky mouse movements and produce jerky mouse movements in the game...

queue_mouse_position_packet only keeps one mouse "positional" packet at a time, so we only send the last one rather than all the mouse movements.
There will be a high cost when sending all mouse movements, so this will need to be an option.

First thing to do is to try to replace queue_mouse_position_packet with queue_priority_packet client.py's send_mouse_position

[Antoine Martin]

Some potentially relevant pointers and thoughts:

• maybe using a different mouse type, a tablet or something that uses absolute positioning would prevent the games/libraries from doing pointer acceleration on our events - which are always lagging by a variable amount of time
• maybe using a different API than Xtest? see below.
• a number of api calls below support a delay parameter, we could set our internal target delay to something close to the highest client latency observed (or 90 percentile?) and then adjust the api delay on our simulated events so that all the events have the same gap between them as on the client. (and if we suddenly get a higher client latency.. increase the target delay to accommodate and go back down slowly?) - should work?

• ​XWarpPointer
• ​XIWarpPointer
• ​XTestFakeRelativeMotionEvent

[Antoine Martin]

See also #770 and in particular r8482 which added XTestFakeMotionEvent and XTestFakeRelativeMotionEvent.

[Antoine Martin]

See also #173

[Antoine Martin]

The !XTest extension is being deprecated, so the way forward is going to be #173.

[migration script]

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