This bug report was migrated from our old Bugzilla tracker.

Reported in version: 1.2.13
Reported for operating system, platform: Windows (NT), x86

Comments on the original bug report:

On 2008-05-26 21:24:31 +0000, Brian Fisher wrote:

On my Windows XP and Vista machines, if the computer is running a synergy server, then SDL's virtual mouse input mode gets all messed up, but only after a key event has been processed...

You can reproduce this with python & pygame, using the script attached to the pygame bug here:
http://pygame.motherhamster.org/bugzilla/show_bug.cgi?id=15

when running the script, if synergy is running, you can see the mouse control seems fine at first, but after a key message is processed (so like press space) then the mouse input gets messed up. The script also lets you press certain other keys (displayed on the window) to switch to other modes to see that it only happens with SDL's virtual mouse input mode, not with normal mouse input.

Also, I've already looked at pygame source, and pygame isn't doing any processing or translation of the mouse messages that would suggest pygame is involved directly.

On 2009-09-21 01:15:52 +0000, Sam Lantinga wrote:

Bryan, can you investigate this bug?

On 2009-09-27 23:29:27 +0000, Sam Lantinga wrote:

I looked into it, and it looks like the issue is that Synergy is not respecting the mouse clipping that SDL is doing.

You can reproduce this with test/testwm in the SDL source archive, and just hit Ctrl-G to grab the mouse in the window.

Interestingly Synergy does the right thing on X11, but thinks the mouse is moving outside the testwm window on Windows.