Synergy-core: Cursor lockout at Windows server login screen

Created on 21 Apr 2016  Â·  25Comments  Â·  Source: symless/synergy-core

Operating Systems

Windows 10 on both

Synergy Version

v1.10.1

Steps to reproduce bug

  1. Move mouse off server screen
  2. See that mouse doesn't appear on client
  3. Unable to move mouse back to server

Workaround by @thatchrisblack https://github.com/symless/synergy-core/issues/5294#issuecomment-318669465

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).

capture


Original report

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.


Related issue #5075

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:

  1. Use a keyboard/mouse connected to the client PC to enter the password and unlock the client.
  2. Kill and restart the synergyc process.
    The server will again be able to control the mouse/keyboard.
bug sprint-should

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:

  1. Try to move cursor between screens. Server and client shold work properly
  2. Lock screen with Win+L
  3. Press Alt+Ctrl+Del
  4. Try to to move cursor between screens. It should not work
  5. Input incorrect password.
  6. You will see error message and button OK
  7. Press button OK
  8. Try to to move cursor between screens multiple times untill mouse and keyboard will freezes.

Note. This scenario 8 of 10 times lead to reproduce described above problem. Unfortunalty it not always reproducible.

All 25 comments

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-f7377d6

CTRL+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 following

Logged 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,
Areg

synergy-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:

  1. Try to move cursor between screens. Server and client shold work properly
  2. Lock screen with Win+L
  3. Press Alt+Ctrl+Del
  4. Try to to move cursor between screens. It should not work
  5. Input incorrect password.
  6. You will see error message and button OK
  7. Press button OK
  8. Try to to move cursor between screens multiple times untill mouse and keyboard will freezes.

Note. This scenario 8 of 10 times lead to reproduce described above problem. Unfortunalty it not always reproducible.

It's realy annoing issue, because

  1. Your keyboard and mouse freezes on server computer and the only workaround to make it work again is to restart client(just click STOP button in client Synergy interface )
  2. To make work symless monitor agait you have to restart both client and server.

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:

  • Server running on Windows (mine being Windows 8.1 for work related reasons though it also happens on 10 for me)
  • Client running on Linux

Steps:

  1. Move mouse to client system
  2. Press Win+L to lock your screens (This works well as it locks both system's screens which I am happy about)
  3. Move the move toward the client screen before unlocking the server

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).

capture

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

Download v1.11.0-rc2

If you find any bugs in the release candidate related to this issue please comment here.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Celant picture Celant  Â·  4Comments

LeTink picture LeTink  Â·  4Comments

jenelcohen picture jenelcohen  Â·  3Comments

nbeazy picture nbeazy  Â·  4Comments

legonigel picture legonigel  Â·  4Comments