locked by mouse buttonID: 0

[sgala]

Operating Systems

Server: Ubuntu 17.04, gnome desktop Client: Ubuntu 16.04.2-LTS

Synergy Version

1.8.8-stable-[a number that the fucking dialog box and my dyslexia impede me to copy] (this is after I upgraded both machines, the previous version was showing the same problem)

Steps to reproduce bug

The set up that used to work, now does not switch windows NEVER. And the log, in debug, shows:

[2017-06-08T10:43:02] DEBUG1: try to leave "chiron" on up [2017-06-08T10:43:02] DEBUG: locked by mouse buttonID: 0 [2017-06-08T10:43:02] DEBUG1: locked to screen

Other info

• When did the problem start to occur? After a trip of three weeks out, so I upgraded probably around 150 ubuntu packages in both machines, and one of them or maybe synergy itself, caused the problem to start happening
• Is there a way to work around it? I have not found it, it is pretty blocking as one of my machines here has no keyboard/mouse
• Does this bug prevent you from using Synergy entirely? Yes

[sgala]

I tried all sorts of stopping and restarting client, server and both, to no avail.

Nevertheless, resetting both client and server computers fixed it, so I guess it is either related with state in the X server in client, server or both...

Sorry for the noise, I leave it open in case is there a better way to detect the failure condition and warn the user that the X server needs restarting, etc....

[vid]

I've been having this problem for a while. I don't know what causes it, it seems to happen randomly, and it's really inconvenient to restart my computer when it happens. I don't ever need the lock feature. I'd appreciate a simple flag to ignore it, if possible.

[sgala]

I don't know what causes it, but I'm getting clues:

• It appears and disappears related with X server state. Closing session and restarting it in the server "fixes" the problem for all the clients at once.
• I have not found a way to fix it by closing applications. Even with all the applications closed it still happens, and it also still happen if I kill synergy at the server and restart it.
• When it is happening, "git gui" (it is a tcl-tk application) has an strage behavior: when I move the cursor over text fields it "extends" the selection, as if I was dragging with the button pressed. When it is not happening moving the cursor over the text fields does not trigger this behavior

[nlyan]

Next time this happens, try hitting Scroll Lock see if that resolves the issue.

I'll leave this open until we get feedback.

[sgala]

I'm not sure if my laptop has a Scroll Lock key. While looking for it. I found something interesting: pressing fn+F12, which produces something like (according to xev):

FocusOut event, serial 33, synthetic NO, window 0x4400001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 33, synthetic NO, window 0x4400001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 36, synthetic NO, window 0x0,
    keys:  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

After this the cursor remains locked in the server screen (my laptop is the server when I'm at home). I'm not sure if F12 is "Scroll Lock", it just has a strange drawing like a number of the other fn+Fnn combinations, but it seems to have a similar effect. The main differente is that the message in the synergy log is quite different. Now it says NOTE: Cursor is locked to screen, check Scroll Lock key while before, as visible in the bug report, it said: DEBUG: locked by mouse buttonID: 0

The bug seems to be related with fullscreen browser canvases such as the ones that webrtc applications or skype use. Something is probably broken in their handling of input state.

I have not seen it in a few days, I'll try the fn-F12 trick when it happens again, thanks

[sgala]

I managed (but I'm not sure how) to make it happen. I was playing with the fn-F12, and I used one key combination that I programmed to be able to shift screen when I'm locked out. It works to go to the client computer (alt-z) sends me there, but I never got it to work to return (alt-c is supposed to make it but it does not work). The only way to return is to press "Apply" in the synergy screen in the client, as it disconnects and the cursor goes back to the server while it reconnects...

When I was locked, I tried fn-F12. In the client it does not work, it shows in the logs:

[2017-07-08T19:32:15] DEBUG1: recv key down id=0x0000ef14, mask=0x0000, button=0x004e
[2017-07-08T19:32:15] DEBUG1: ignored key ef14 0000
[2017-07-08T19:32:15] DEBUG1: recv key up id=0x0000ef14, mask=0x0000, button=0x004e

(this is fn-F12, which in the server causes the following:

[2017-07-08T19:34:39] NOTE: cursor locked to current screen

In the server trying to go to the client, then pressing fn-F12, then trying again it does:

[2017-07-08T19:28:05] DEBUG: locked by mouse buttonID: 0
[2017-07-08T19:28:05] DEBUG: locked by mouse buttonID: 0
[2017-07-08T19:28:08] NOTE: cursor locked to current screen
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:09] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:10] NOTE: Cursor is locked to screen, check Scroll Lock key
[2017-07-08T19:28:10] NOTE: cursor unlocked from current screen
[2017-07-08T19:28:12] DEBUG: locked by mouse buttonID: 0
[2017-07-08T19:28:12] DEBUG: locked by mouse buttonID: 0

The bug is still there, and the only workaround is restarting X in the server (restarting synergy does not work)

[vid]

I think at least one instance may be related to trying (accidentally) to switch to another screen while in "Exposé" (super-W) in Unity. I guess some flag gets tripped and from there I can't switch screens, even after I exit from Exposé. This is with 1.6.2 on both Ubuntu systems.

[sgala]

Another data point:

• Aug 1st (time of first error: 2017-08-01T22:57:57) it happened again to me. I had a full screen meet.jitsi.me video chat (but in my own server) and I pressed "ESC" to come back from full screen or else I clicked in the phone icon to end the call... and when I went to the other screen it was not working.
• As I already commented, I have a workaround using a keyboard shortcut to switch from server to client, and clicking in apply (the shortcut does not work in the client) to come back. So I didn't restart X and kept using like this.
• The chat was running on Chromium, I closed chromium, still failing...
• I moved my laptop, switched it from server to client and used it in my office, etc. Everything ok.
• When I came back home and switched back to server, all was the same. The error there.
• Today, at 2017-08-03T15:15:46 it started working again. Apparently nothing happened that could justify the change. I was not using any canvas, chromium was off...

I wonder if a long timeout of 145000 or 150000 seconds for any Xorg or kernel could be involved, or if it is purely random, but it is driving me crazy. What is clear is that once it is happening, only restarting X (in the server) guarantees that it disappears... except when it randomly stops happening. I'll keep the long testing to see if the timing is consistent.

[arcaartem]

I have a very similar issue but on Macbooks. Move the mouse out of the server into the client, right click and more frequently than not, the pointer will be jailed in the client. I have to close both server and client apps in order to resume normal operation. Btw, right click action will be applied to both in those instances (i.e. both server and client will trigger right click action)

[OmgImAlexis]

If found this on a forum and has fixed the issue for me. Add a hotkey using the settings below and then once it's done you can just press that button to unlock the cursor. I found my Macbook randomly has this issue and every time since this has fixed it.

Maybe there needs to be a button in the UI to enable/disable the locked cursor.

key: right mouse click ( mousebutton(3) )
function: Lock Cursor to screen: On
Toggle radio button "Hot key is pressed"

[lovejoy]

i tried right click can resolve this

[gustavold]

I have the same problem. I don't have a Scroll Lock key on my laptop, but I can emulate it with "xdotool key Scroll_Lock".

If I turn Scroll Lock on then try to move the cursor out of the server this is the log from synergys:

Jul 31 10:21:43 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:21:43] NOTE: cursor locked to current screen
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/server/Server.cpp,1492
Jul 31 10:21:47 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:21:47] NOTE: Cursor is locked to screen, check Scroll Lock key
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/server/Server.cpp,426
Jul 31 10:21:47 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:21:47] NOTE: Cursor is locked to screen, check Scroll Lock key
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/server/Server.cpp,426
Jul 31 10:21:47 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:21:47] NOTE: Cursor is locked to screen, check Scroll Lock key
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/server/Server.cpp,426
Jul 31 10:21:47 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:21:47] NOTE: Cursor is locked to screen, check Scroll Lock key
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/server/Server.cpp,426

Now turn off Scroll Lock again and try to move the cursor out of the server:

Jul 31 10:25:38 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:25:38] NOTE: cursor unlocked from current screen
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/server/Server.cpp,1492
Jul 31 10:25:41 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:25:41] DEBUG: locked by mouse buttonID: 0
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/synergy/Screen.cpp,377
Jul 31 10:25:41 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:25:41] DEBUG: locked by mouse buttonID: 0
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/synergy/Screen.cpp,377
Jul 31 10:25:41 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:25:41] DEBUG: locked by mouse buttonID: 0
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/synergy/Screen.cpp,377
Jul 31 10:25:41 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:25:41] DEBUG: locked by mouse buttonID: 0
                                             /builddir/build/BUILD/synergy-core-1.8.8-stable/src/lib/synergy/Screen.cpp,377
Jul 31 10:25:41 moss synergys[7381]: Synergy 1.8.8: [2018-07-31T10:25:41] DEBUG: locked by mouse buttonID: 0

[arooni]

does trying another version of synergy work for anyone?

[gustavold]

I did some debugging and found that XQueryPointer() was always returning Button1 pressed. It sounds like a Xorg bug... in my case, it seems it was related to the touchscreen... because when I touched the screen, suddenly something unclogged and synergy started working fine again. I rarely use the touchscreen in my laptop. That is why it didn't occur to me to try it earlier.

I guess Xorg has separate states for each input pointer (usb mouse, touchpad, touchscreen, etc), but XQueryPointer() doesn't provide enough semantics to deal with such complex setup... Either XQueryPointer() needs fixing to avoid leaking the separate states abstraction, or we need a more fine grained api and let synergy deal with such details.

[arooni]

you're amazing! i spent 1 hour trying different things. when i moved my finger on the touchpad it made everything work great!

also found that disabling the touchpad is another approach. i normally use my thinkpad's red nub button so i am surprised my touchpad was even on.

thanks for saving me $29 as well :P

[arooni]

by the way; what's the last version that we can compile? 1.9.1 ? i was trying that approach on my mac host and couldn't seem to get past the qt library errors

[arooni]

well just for funsies; i compiled the open source version of synergy and i still have this issue even on latest stable and on latest beta version.

locked by mouse button 0

seeing on mac host (server) and ubuntu (client)

[arooni]

Just to confirm this affects 1.10 stable.

It's hard to justify paying money for software when the team hasn't addressed a bug that was reported a year ago.

Perhaps it's because they don't view Ubuntu users as a priority. @nbolton @nlyan

[nbolton]

It's hard to justify paying money for software when the team hasn't addressed a bug that was reported a year ago.

Thanks for raising a concern. We prioritize issues based on the number of users affected (we never go by age of issue). Would you like a refund? Please contact us if you'd like one.

[rewtd]

I had the same issue and a comment made earlier got me thinking. In my case it's the touchscreen on my laptop. The issue is not with Synergy at all but because the touch screen was activated in some way. Taping the screen once resolves the issue for me.

[JoshuaAYoung]

I have two 2017 macbook pros (no touchscreen obviously) and having this same issue. Pretty ridiculous that this is still an issue 3 years later, and the official response of "You can have a refund but we're not gonna do anything about it" is pretty frustrating. At least have the decency to lie to us. xD

I have tried all of the solutions in this issue with no luck. I have to click "Apply" on the client side synergy app, which takes me back to the server window, where I right click anywhere and that seems to fix the issue. Happens whenever I right click on anything in the finder or in the dock on the client side (which is how I open things in vscode, which is all day)... Oddly when the issue happens, the server side window does a right click and the cursor comes up, but I'm still on the client side and can't get the cursor over to the server.

[airgapper]

For external, usb mice, try unpluging / replug dongle. Fixes every time for me.

[mrled]

Interesting, I had an issue with this too.

I have a Synergy server running on Linux, and two macOS clients. All are running the latest version of Synergy as of the time of this writing. I had recently added the Apple Magic Trackpad to the server (via Bluetooth) as an alternative mousing device, but mostly don't use it. I stepped away from my desk for a bit, and found that my cursor was locked to the screen.

Touching the Magic Trackpad unlocked it. Very surprising behavior. Touching the trackpad again didn't lock it again, so I'm not sure how to trigger it.

[github-actions[bot]]

This issue is stale because it has been open 1 year with no activity. Remove the stale label or add a comment, otherwise this will be closed in 30 days.