Mark Colestock Posted May 26, 2015 Share Posted May 26, 2015 Version 1.7.2 on Ubuntu, and 1.7.2 on Windows 7. My Ubuntu is my server and windows 7 is client computer. I often bump into situation where mouse gets stuck in one screen or the other and won't cross over. Bringing up the console - hitting apply on the screen where the mouse is active, will make it start working again. But this blockage happens many times a day- and gets frustrating to have to reset it each time to get it going again. Currently have turned off the SSL feature- I was thinking that was causing the problem, but it happens running in non-SSL mode as well. Any suggestions on how to fix this issue? Link to comment Share on other sites More sharing options...
Ben Koenig Posted May 26, 2015 Share Posted May 26, 2015 Sounds like maybe you are getting disconnected for some reason? Hitting Are you using a WIFI connection? Also worth looking into is the "Auto Config" option. A little more info about your network and configuration options will be very helpful. Link to comment Share on other sites More sharing options...
Mark Colestock Posted May 27, 2015 Author Share Posted May 27, 2015 I was thinking it might be disconnecting as well- but that doesn't explain the mouse getting stuck on the client side, where it works just fine, but can't move back to Server side, until I do a client stop/start or hit the apply button (not sure what this button is doing). As far as network, I do have a hardwired network, but my laptop (Windows 7) also connects to wireless as a second network from time to time. Going to try disabling the wireless today, and see if things improve. I see 1.7.3 just came out, so I may also try that tomorrow after I see if dropping my wireless helps today or not. Link to comment Share on other sites More sharing options...
Mark Colestock Posted June 2, 2015 Author Share Posted June 2, 2015 I am still having trouble with mouse getting stuck. Recently tried the 1.7.3 upgrade without the SSL turned on for now. Wanted to minimize issues that might be causing loss of functionality. Have hardwired ethernet connections with no wireless turned on. Windows 7 on laptop, and Ubuntu 14.04 desktop. However the mouse mostly gets stuck on server side, but does occasionally get stuck on client side as well. This happens many times a day- which is frustrating- when I am in a hurry to create a document; I have to stop and deal with getting the mouse to work again. Synergy didn't used to have this issue- seems like it has only come up in the 1.7.x era of changes. Any suggestions would be appreciated. Not sure how to debug this further. Link to comment Share on other sites More sharing options...
jacob lunde Posted June 3, 2015 Share Posted June 3, 2015 I am having the same issue, once it gets close to the edge of the win (10) server it gets grabbed and put to the lowest right point on the Linux (fedora 21) client. Didn't start till updated to 10130 on win 10 Link to comment Share on other sites More sharing options...
Alberson Melo Posted June 3, 2015 Share Posted June 3, 2015 Yep, same problem here. Just bought the software. The mouse is stuck in the bottom-right edge of the client screen. As I turned debug on, it seems that the resolution of the client was wrong, it has a 1080p resolution and Synergy log said otherwise: [code]DEBUG: received client "Notebook" info shape=0,0 1536x864 at 0,0[/code] Any help is appreciated Link to comment Share on other sites More sharing options...
Binit Ranjan Mishra Posted June 4, 2015 Share Posted June 4, 2015 I am facing the same issue. My server is running windows 8.1 OS and Synergy 1.7.3 64 bit. The client machine is running windows 10 OS and Synergy 1.7.3 64 bit. I am a first time user and installed and configured synergy on my machines interactively and haven't had it working at all. I set the logging mode to debug on both my client and server machines and this what I have : Server: INFO: entering screen INFO: switch from "BRAHMASMI" to "Samarthak" at 1919,510 INFO: leaving screen DEBUG: open clipboard DEBUG: close clipboard DEBUG: ignored screen "BRAHMASMI" update of clipboard 0 (unchanged) DEBUG: open clipboard DEBUG: close clipboard DEBUG: ignored screen "BRAHMASMI" update of clipboard 1 (unchanged) INFO: switch from "Samarthak" to "BRAHMASMI" at 187,502 INFO: entering screen Client: INFO: entering screen DEBUG: start receiving clipboard data INFO: leaving screen ERROR: corrupted clipboard data, expected size=215 actual size=0 INFO: entering screen DEBUG: start receiving clipboard data INFO: leaving screen ERROR: corrupted clipboard data, expected size=215 actual size=0 Observations: Clipboard data actually copies over fine. However, the mouse control does not move from the server screen to the client screen. When I take the mouse cursor to the edge of the server screen, it immediately bounces back to a lower central position on the same screen. If I keep doing this enough number of times though, I lose control of the mouse altogether and when I press the CTRL key to locate the cursor, it shows up on both screens. Link to comment Share on other sites More sharing options...
jacob lunde Posted June 4, 2015 Share Posted June 4, 2015 Yeah mine are all showing leaving the screen at -271,xxxx. -- Fixed it, -- This is the old problem of using scaling at all. I have twi displays on the windows machine and three on the linux, I had scaling turned on witht he windows machine and thats what caused all of this. Hope this helps others. Link to comment Share on other sites More sharing options...
Daniel Branstrator Posted June 8, 2015 Share Posted June 8, 2015 [quote="jacob lunde"]Yeah mine are all showing leaving the screen at -271,xxxx. -- Fixed it, -- This is the old problem of using scaling at all. I have twi displays on the windows machine and three on the linux, I had scaling turned on witht he windows machine and thats what caused all of this. Hope this helps others.[/quote] So, this actually worked. Thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.