blaberry
commented
6 years ago Update:
When FSL is running on the Synergy server, the behavior is incorrect.
The mouse is still able to be moved to the second machine's screen, if that screen borders the one the cursor is locked to. As long as the clients do not border the monitor with the lock however, you should be good.
When FSL is running on the Synergy client, the behavior is much worse.
The mouse still gets sent coordinates which correspond to the second screen. This results in the cursor getting stuck on the clipped border, until the cursor is moved far enough towards the locked-onto screen. Using relative or absolute mouse movements on the server does not alleviate this problem.
Good solution:
For serverside FSL, we might be able to use an IPC-call to the synergy service, send a SIGPAUSE or stop it completely while locked on. For clientside FSL, there's no solution but to redo how synergy sends cursor movement, afaik.
Bad solution:
Maybe warn user about synergy behaving strangely.
Synergy does a lot of stuff with the mouse. Most interesting is probably mouse movement on the master computer. Clients running FSL shouldn't be as bad off. Either way, make sure
Other things: There is a key command for toggling between local and relative mouse coords in synergy, can we send an IPC message saying "hey syn we're locked onto this window now" and change to local coords? Would be dope.