Windows 10 on both
v1.10.1
Same issue here as well. One workaround is to set up a hotkey to switch screens back to your Windows server in the server configuration options. Just make sure to have it only apply on the client machine(s).
I am using Synergy between two Windows machines. One (Synergy Server) is a Windows 10 machine. The other (Synergy Client) is a Win 7 machine. I have the "Elevated Mode" box check on both. When I lock the Windows 7 Machine, I have about 5 seconds to stop Synergy Server, or my mouse and keyboard stop responding on the Synergy Server. The are completely locked up and the only thing I can do is restart. I'm running Synergy Pro v1.7.6 on both.
Running synergy-v1.7.5-rc1-ceab3a8 on both machines
Server: Windows 7 Enterprise SP1 64-bit (on left)
Client: Linux Mint 17.2 Cinnamon 64-bit (on right)
If both systems are showing a login or unlock screen, and I move the mouse beyond the right edge of the server display, the mouse does not appear on the client display. Even though the mouse is not displaying, the client has control of it, and moving the mouse back to the left will not return it to the server display. In essence, control is now trapped on the client, where you cannot actually do anything with it.
The only way to unlock the systems once this happens is:
What happens if you stop the service or program on Windows 7 machine (client)?
If I stop the service on either machine, the mouse and keyboard come back.
I am experiencing a similar issue with 3 machines. Arch, and two Windows 7 boxes. Windows 7 is the "server" and when the screen is locked I'll be stuck on either the arch box or the other windows box if it's on (laptop). If I kill the service on the one I'm stuck on I can regain control of the server but if I accidentally switch screens to the other machine before I log in I'm stuck again until I kill that service. After login, no issues.
Presumably this is Windows trying to stop programs from stealing user login credentials. Noted.
Something similar happened here. :) In my scenario, Client is a win7 (left), server is a win8 (right).
When I use an rdp session to connect to my win8 (from a tablet), the server locks out the user, and displays login screen (original screen can be shown on the tablet). So... In this case, no way to move the mouse back to the server, stays on the client (most left side). Mouse x is always zero (y is changable). When I tried to move mouse to the right direction, nothing happened but:
[2016-05-24T23:09:20] DEBUG1: try to leave "Client" on left
[2016-05-24T23:09:20] DEBUG1: no neighbor left
[2016-05-24T23:09:20] DEBUG: dropped bogus delta motion: -956,+59
Assume: after lock out, the server side width reduced to zero, and something went wrong...
Come to think of it, when mine has locked it's been after using RDP to access the server from my phone or my laptop.
I am using Synergy 1.7.6 with a Windows Server,and a linux Fedora client.
When the windows server is locked (for example away from keyboard), and then I go to unlock it, synergy has retained focus on the client machine and sends the password there.
I have to disconnect the server physically, or kill synergy processes on the client to be able to unlock the server again.The mouse pointer has disappeared, and cannot be moved back to the server.
Elevate mode does not have any effect.
I am facing similar issues. Using two Win7 machines, and when I try to lock Windows session with WinKey + L, after a few minutes The mouse/keyboard are locked on the client machine.
Same issue here -
Server - Windows 10 with dual screens
Client - Single Screen Windows 7
Version: Synergy Pro 1.8.1-beta-f7377d6CTRL+ALT+DEL to the Client doesn't work at all and I lock my machines several times a day and have to use the other keyboard. Never works at all.
I observed this info in the Log:
[2016-07-15T15:44:44] INFO: switch from "CS00006189" to "tux164" at 3830,1079
[2016-07-15T15:44:45] INFO: entering screen
[2016-07-15T15:44:45] INFO: switch from "tux164" to "CS00006189" at 0,1061
[2016-07-15T15:44:45] INFO: leaving screen
[2016-07-15T15:44:50] NOTE: client "CS00006189" has disconnected
[2016-07-15T15:44:50] INFO: jump from "CS00006189" to "tux164" at 960,540
[2016-07-15T15:44:50] INFO: entering screen
[2016-07-15T15:44:56] INFO: OpenSSL 1.0.2 22 Jan 2015
[2016-07-15T15:44:56] NOTE: accepted client connection
[2016-07-15T15:44:56] INFO: accepted secure socket
[2016-07-15T15:44:56] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-07-15T15:44:56] NOTE: client "CS00006189" has connected
[2016-07-15T15:45:05] INFO: switch from "tux164" to "CS00006189" at 0,662
[2016-07-15T15:45:05] INFO: leaving screen
[2016-07-15T15:45:08] NOTE: disconnecting client "CS00006189"
[2016-07-15T15:45:08] INFO: jump from "CS00006189" to "tux164" at 960,540
[2016-07-15T15:45:08] INFO: entering screen
[2016-07-15T15:45:08] NOTE: client "CS00006189" has disconnected
[2016-07-15T15:45:09] NOTE: stopped server
[2016-07-15T15:45:09] WARNING: detected application not running, pid=12924
[2016-07-15T15:45:10] INFO: backing off, wait=2s, failures=1
[2016-07-15T15:45:12] INFO: starting new process
[2016-07-15T15:45:12] INFO: activeDesktop:Default
[2016-07-15T15:45:12] INFO: starting new process
[2016-07-15T15:45:13] INFO: drag and drop enabled
[2016-07-15T15:45:13] ERROR: failed to get desktop path, no drop target available, error=2
[2016-07-15T15:45:13] NOTE: started server, waiting for clients
[2016-07-15T15:45:13] INFO: watchdog status: ok
[2016-07-15T15:45:19] INFO: OpenSSL 1.0.2 22 Jan 2015
[2016-07-15T15:45:19] NOTE: accepted client connection
[2016-07-15T15:45:19] INFO: accepted secure socket
[2016-07-15T15:45:19] INFO: AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
[2016-07-15T15:45:19] NOTE: client "CS00006189" has connected
Hi Team
I have something similar to #5397 but in my case I can constantly reproduce problem and it is happening on both 1.7 and latest 1.8 beta:
Server side Win 7 x64
Client side CentOS release 6.7 (Final) "Linux 2.6.32-573.18.1.el6.x86_64 #1 SMP Tue Feb 9 22:46:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux"
Synergy 1.8.1 both sides
Scenario is the followingLogged in to Windows: I can move mouse between the Server and client without any problem and lock and unlock CentOs screen without problems.
Locking windows screen Interesting stuff starting from this stage. If mouse in windows area I can press Ctrl+Alt+Del and unlock windows without the problem. While Windows locked I will try to move mice to the Linux area it goes crazy and stucks in Linux top right screen. I can type in Linux side to unlock the screen but I can't use mouse - only keyboard. I can press Ctrl+Alt+Del but it does not affect Linux side at all - it onl affect Windows side as it bring login prompt which is unusable as mice and keyboard are on Client side.
Please see some debug logs from server and client ...
Please let me know if you need more.Regards,
Aregsynergy-debug001.log.4392.txt
synergy-debug001.log.4393.txt
synergy-debug001.log.4394.txt
synergy-debug002.log.11962.txt
synergy-debug002.log.11963.txt
synergy-debug002.log.11964.txt
synergy-server.txt
So this is confirmed?
I've only ever seen it after logging in via RDP to the server machine. If I lock workstation it doesn't happen. Like others it appears to be stuck to one spot like a corner of one of the client screens. Sometimes if you move mouse far and fast enough you can break out of it and back to the server machine.
Sent from my iPhone
On Jul 18, 2016, at 15:59, Areg [email protected] wrote:
So this is confirmed?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Same problem on Windows 10(server) and OSX 10.11.5(client) Synergy version 1.8.1-beta-f7377d6
Step to reproduce:
Note. This scenario 8 of 10 times lead to reproduce described above problem. Unfortunalty it not always reproducible.
It's realy annoing issue, because
I'm usualy like to do not stop Synergy at all to just make possible put my laptop near computer and it just start synhronize when it in same network. But this bug makes it impossible because my PC usually locked and then this bug appears.
Yes this Issue mages Synergy unusable. Very sad. After years of beeing happy with SynergyI had to change to "Mouse Without Borders" by Microsoft.
and now latest Beta wont start at all ...
ERROR: failed to get desktop path, no drop target available, error=2
I am using version 1.8.8-stable-c30301e on Windows 7 enterprise as the server, and 2 Ubuntu systems as clients using the same version of Synergy.
When the Windows server locks, if I move the mouse cursor outside of the server's screen then I can't get it back to the server and it means that I can't enter the password to unlock the server. The only solution is to power cycle the server which is VERY annoying.
I have tried to create a hotkey to cause a "switchToScreen" to the server, but it doesn't work when the server is locked.
For what it's worth I've found that the command "killall synergc" will bring the focus back to the server (or sudo killall...) and the synergy daemon will restart synergyc within a few seconds.
If it's windows host and client I've had to get on the client machine and temporarily stop the service until logged back in.
This is really the only bug I have a problem with in synergy at the moment but it's a big one.
Sent from my iPhone
On Mar 27, 2017, at 10:42, Mario Beaulieu notifications@github.com wrote:
I am using version 1.8.8-stable-c30301e on Windows 7 enterprise as the server, and 2 Ubuntu systems as clients using the same version of Synergy.
When the Windows server locks, if I move the mouse cursor outside of the server's screen then I can't get it back to the server and it means that I can't enter the password to unlock the server. The only solution is to power cycle the server which is VERY annoying.
I have tried to create a hotkey to cause a "switchToScreen" to the server, but it doesn't work when the server is locked.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Thanks c0ldg0ld
I just had to try it. Stopping the client brings the focus back to the server.
It is very easy to replicate my side as well... I'm just putting my steps as it seems two steps easier than I've seen above
Setup:
Steps:
At this point I hit this issue. When mine locks, the mouse is locked from any movement but the keyboard keystrokes still work. I can therefore unlock the client machine and work with only keyboard access.
Of course you could use the terminal to stop the synergy client but another way I get it working is unplugging the client and waiting until the server loses connection.
This is of course nowhere near an actual solution though.
Windows 10 server, Mac client.
Whenever I use CMD+L on Mac to move focus in my browser to the URL bar, the Windows server locks, and the cursor becomes trapped on the client, requiring a server restart.
I have switched the server to be on the Mac in order to work around this issue.
Same issue here as well. One workaround is to set up a hotkey to switch screens back to your Windows server in the server configuration options. Just make sure to have it only apply on the client machine(s).
ThanksIt works!I used to keep mice from other computers handy so I could temporarily deactivate Synergy on other computers and that gave control of the server mouse back in server's screen.What you describe is a better way. Sent from my BlackBerry - the most secure mobile device - via the Rogers Network From: [email protected]: July 28, 2017 10:38To: [email protected]: [email protected]: beaulieu.[email protected]; [email protected]: Re: [symless/synergy] Cursor traps on client while Windows server screen is locked (#5294) Same issue here as well. One workaround is to set up a hotkey to switch screens back to your Windows server in the server configuration options. Just make sure to have it only apply on the client machine(s).
—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or mute the thread.
@thatchrisblack Thanks it works
A release candidate is available that incorporates a fix for this issue
If you find any bugs in the release candidate related to this issue please comment here.
Most helpful comment
Same problem on Windows 10(server) and OSX 10.11.5(client) Synergy version 1.8.1-beta-f7377d6
Step to reproduce:
Note. This scenario 8 of 10 times lead to reproduce described above problem. Unfortunalty it not always reproducible.