[GH-ISSUE #500] Mouse sticking to upper left of screen on client device, constant up/left velocity on mouse?

gitea-mirror commented

2026-05-05 06:15:17 -06:00

Owner

Originally created by @rspilk on GitHub (Nov 19, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/500

Operating Systems

Server: Windows 10 Edu - 1809

Client: Arch Linux x86_64 Linux kernel 5.3.10-arch1-1 running i3

Barrier Version

2.3.2 (server and client)

Steps to reproduce bug

The issue happens all the time and barrier is completely unusable. Was working perfectly on this same version but unsure what has caused mouse behavior to change.

Orient client to left of server
Connect client to server successfully
Move mouse to the left to the client
Mouse is stuck to far upper left of screen, high mouse velocity might get it back to server but generally requires disconnecting to get mouse back on server.

Other info

When did the problem start to occur? It began last week
Is there a way to work around it? No
Does this bug prevent you from using Barrier entirely? Yes

Setting DEBUG2 in logs doesn't give me any info, it appears like there is a left/up velocity always on the mouse cursor on the client that I cannot remove. Issue persists on re installation of barrier on client and server. Barrier was working perfectly in i3 previously, I am unsure how to troubleshoot what caused the fault to begin as nothing is logged and googling is only yielding me issues here that have apparently been resolved.

Any troubleshooting steps to address would be appreciated.

Originally created by @rspilk on GitHub (Nov 19, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/500 ### Operating Systems ### Server: Windows 10 Edu - 1809 Client: Arch Linux x86_64 Linux kernel 5.3.10-arch1-1 running i3 ### Barrier Version ### 2.3.2 (server and client) ### Steps to reproduce bug ### The issue happens all the time and barrier is completely unusable. Was working perfectly on this same version but unsure what has caused mouse behavior to change. 1. Orient client to left of server 2. Connect client to server successfully 3. Move mouse to the left to the client 4. Mouse is stuck to far upper left of screen, high mouse velocity might get it back to server but generally requires disconnecting to get mouse back on server. ### Other info ### * When did the problem start to occur? It began last week * Is there a way to work around it? No * Does this bug prevent you from using Barrier entirely? Yes Setting DEBUG2 in logs doesn't give me any info, it appears like there is a left/up velocity always on the mouse cursor on the client that I cannot remove. Issue persists on re installation of barrier on client and server. Barrier was working perfectly in i3 previously, I am unsure how to troubleshoot what caused the fault to begin as nothing is logged and googling is only yielding me issues here that have apparently been resolved. Any troubleshooting steps to address would be appreciated.

gitea-mirror added the

bug

windows

linux

labels 2026-05-05 06:15:17 -06:00

gitea-mirror commented

2026-05-05 06:15:22 -06:00

Author

Owner

@rspilk commented on GitHub (Nov 25, 2019):

I rebuilt my client machine using lubuntu instead of arch, same behavior in both lxqt and i3 on this platform

@rspilk commented on GitHub (Nov 25, 2019): I rebuilt my client machine using lubuntu instead of arch, same behavior in both lxqt and i3 on this platform

gitea-mirror commented

2026-05-05 06:15:26 -06:00

Author

Owner

@rspilk commented on GitHub (Nov 27, 2019):

I have completely uninstalled the application from both the lubuntu computer and the windows 10 pc. I have removed the files from ProgramData, AppData on the windows machine, and everywhere i could find any reference to them. I have reinstalled and still have the same behavior.

I have played with relative mouse settings, and still have no idea how to continue with fixing this, debug2 does not explain the behavior

@rspilk commented on GitHub (Nov 27, 2019): I have completely uninstalled the application from both the lubuntu computer and the windows 10 pc. I have removed the files from ProgramData, AppData on the windows machine, and everywhere i could find any reference to them. I have reinstalled and still have the same behavior. I have played with relative mouse settings, and still have no idea how to continue with fixing this, debug2 does not explain the behavior

gitea-mirror commented

2026-05-05 06:15:29 -06:00

Author

Owner

@rspilk commented on GitHub (Nov 27, 2019):

Okay, so I ran barriers.exe to attempt to figure this out, I have the following config manually defined:

# +-------+  +--------+
 # |Laptop |  |Desktop1|
 # |       |  |        |
 # +-------+  +--------+

 section: screens
 	Laptop:
 	Desktop1:
 end

section: links
 	# Laptop is to the left of Desktop1
 	Desktop1:
 		left  = Laptop
 	# Desktop1 is to the right of Laptop
 	Laptop:
 		right = Desktop1
 end


 section: aliases
 	Laptop:
 		ansible
 	Desktop1:
 		XXXX-12345L
 end

I see the following messages:

[2019-11-27T07:35:23] DEBUG2: reading secure socket
[2019-11-27T07:35:23] DEBUG2: reading secure socket
[2019-11-27T07:35:23] DEBUG2: reading secure socket
[2019-11-27T07:35:23] DEBUG2: want to read, error=2, attempt=1
[2019-11-27T07:35:23] DEBUG2: msg from "ansible": CALV
[2019-11-27T07:35:23] DEBUG2: msg from "ansible": CNOP
[2019-11-27T07:35:23] DEBUG2: no-op from
[2019-11-27T07:35:24] DEBUG2: onMouseMoveSecondary -210,-133
[2019-11-27T07:35:24] DEBUG2: find neighbor on left of "Laptop"
[2019-11-27T07:35:24] DEBUG2: no neighbor on left of "Laptop"
[2019-11-27T07:35:24] DEBUG1: try to leave "Laptop" on left
[2019-11-27T07:35:24] DEBUG1: no neighbor left
[2019-11-27T07:35:24] DEBUG2: clamp to left of "Laptop"
[2019-11-27T07:35:24] DEBUG2: clamp to top of "Laptop"
[2019-11-27T07:35:24] DEBUG2: onMouseMoveSecondary -210,-132
[2019-11-27T07:35:24] DEBUG2: find neighbor on left of "Laptop"
[2019-11-27T07:35:24] DEBUG2: no neighbor on left of "Laptop"
[2019-11-27T07:35:24] DEBUG1: try to leave "Laptop" on left
[2019-11-27T07:35:24] DEBUG1: no neighbor left
[2019-11-27T07:35:24] DEBUG2: clamp to left of "Laptop"
[2019-11-27T07:35:24] DEBUG2: clamp to top of "Laptop"
[2019-11-27T07:35:24] DEBUG2: onMouseMoveSecondary -210,-132
[2019-11-27T07:35:24] DEBUG2: find neighbor on left of "Laptop"
[2019-11-27T07:35:24] DEBUG2: no neighbor on left of "Laptop"
[2019-11-27T07:35:24] DEBUG1: try to leave "Laptop" on left
[2019-11-27T07:35:24] DEBUG1: no neighbor left
[2019-11-27T07:35:24] DEBUG2: clamp to left of "Laptop"
[2019-11-27T07:35:24] DEBUG2: clamp to top of "Laptop"
[2019-11-27T07:35:26] DEBUG2: writef(CALV)
[2019-11-27T07:35:26] DEBUG2: wrote 4 bytes
[2019-11-27T07:35:26] DEBUG2: writing secure socket:000001664EC18DC0

The issue lines I am seeing are the "clamp to top and left" which is the behavior im seeing

@rspilk commented on GitHub (Nov 27, 2019): Okay, so I ran barriers.exe to attempt to figure this out, I have the following config manually defined: ``` # +-------+ +--------+ # |Laptop | |Desktop1| # | | | | # +-------+ +--------+ section: screens Laptop: Desktop1: end section: links # Laptop is to the left of Desktop1 Desktop1: left = Laptop # Desktop1 is to the right of Laptop Laptop: right = Desktop1 end section: aliases Laptop: ansible Desktop1: XXXX-12345L end ``` I see the following messages: ``` [2019-11-27T07:35:23] DEBUG2: reading secure socket [2019-11-27T07:35:23] DEBUG2: reading secure socket [2019-11-27T07:35:23] DEBUG2: reading secure socket [2019-11-27T07:35:23] DEBUG2: want to read, error=2, attempt=1 [2019-11-27T07:35:23] DEBUG2: msg from "ansible": CALV [2019-11-27T07:35:23] DEBUG2: msg from "ansible": CNOP [2019-11-27T07:35:23] DEBUG2: no-op from [2019-11-27T07:35:24] DEBUG2: onMouseMoveSecondary -210,-133 [2019-11-27T07:35:24] DEBUG2: find neighbor on left of "Laptop" [2019-11-27T07:35:24] DEBUG2: no neighbor on left of "Laptop" [2019-11-27T07:35:24] DEBUG1: try to leave "Laptop" on left [2019-11-27T07:35:24] DEBUG1: no neighbor left [2019-11-27T07:35:24] DEBUG2: clamp to left of "Laptop" [2019-11-27T07:35:24] DEBUG2: clamp to top of "Laptop" [2019-11-27T07:35:24] DEBUG2: onMouseMoveSecondary -210,-132 [2019-11-27T07:35:24] DEBUG2: find neighbor on left of "Laptop" [2019-11-27T07:35:24] DEBUG2: no neighbor on left of "Laptop" [2019-11-27T07:35:24] DEBUG1: try to leave "Laptop" on left [2019-11-27T07:35:24] DEBUG1: no neighbor left [2019-11-27T07:35:24] DEBUG2: clamp to left of "Laptop" [2019-11-27T07:35:24] DEBUG2: clamp to top of "Laptop" [2019-11-27T07:35:24] DEBUG2: onMouseMoveSecondary -210,-132 [2019-11-27T07:35:24] DEBUG2: find neighbor on left of "Laptop" [2019-11-27T07:35:24] DEBUG2: no neighbor on left of "Laptop" [2019-11-27T07:35:24] DEBUG1: try to leave "Laptop" on left [2019-11-27T07:35:24] DEBUG1: no neighbor left [2019-11-27T07:35:24] DEBUG2: clamp to left of "Laptop" [2019-11-27T07:35:24] DEBUG2: clamp to top of "Laptop" [2019-11-27T07:35:26] DEBUG2: writef(CALV) [2019-11-27T07:35:26] DEBUG2: wrote 4 bytes [2019-11-27T07:35:26] DEBUG2: writing secure socket:000001664EC18DC0 ``` The issue lines I am seeing are the "clamp to top and left" which is the behavior im seeing

gitea-mirror commented

2026-05-05 06:15:32 -06:00

Author

Owner

@rspilk commented on GitHub (Nov 27, 2019):

I solved the issue with a workaround for anyone looking for this in the future. I found the following link related to synergy

It describes the issue as being caused by high DPI settings. To solve it do the following in Windows 10:

Navigate to the install path of Barrier in explorer.exe (default: C:\Program Files\Barrier)
Right click on barriers.exe, select properties, click Compatibility tab
Click "Change Settings for All Users"
Click on "Change high DPI settings
Check the box "Override high DPI scaling behavior"
Select Scaling performed by: Application
click OK through the open boxes and reconnect synergy

This bug seems to be something to do with my resolution settings? I am not sure. I never experienced this before

@rspilk commented on GitHub (Nov 27, 2019): I solved the issue with a workaround for anyone looking for this in the future. I found the following [link ](https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1340272) related to synergy It describes the issue as being caused by high DPI settings. To solve it do the following in Windows 10: 1) Navigate to the install path of Barrier in explorer.exe (default: C:\Program Files\Barrier) 2) Right click on barriers.exe, select properties, click Compatibility tab 3) Click "Change Settings for All Users" 4) Click on "Change high DPI settings 5) Check the box "Override high DPI scaling behavior" 6) Select Scaling performed by: Application 7) click OK through the open boxes and reconnect synergy This bug seems to be something to do with my resolution settings? I am not sure. I never experienced this before

gitea-mirror commented

2026-05-05 06:15:34 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 1, 2020):

Is this issue still an issue for you? Please do comment and let us know! Alternatively, you may close the issue yourself if it is no longer an problem

@github-actions[bot] commented on GitHub (Oct 1, 2020): Is this issue still an issue for you? Please do comment and let us know! Alternatively, you may close the issue yourself if it is no longer an problem

gitea-mirror commented

2026-05-05 06:15:37 -06:00

Author

Owner

@AstralStorm commented on GitHub (Jan 11, 2021):

Confirmed with 2.3.3-release-743515e7 - with both server and client Windows 10 x64, one Insider 201024-2009, the other 1909.
Workaround on server side avoids the problem.

@AstralStorm commented on GitHub (Jan 11, 2021): Confirmed with 2.3.3-release-743515e7 - with both server and client Windows 10 x64, one Insider 201024-2009, the other 1909. Workaround on server side avoids the problem.

gitea-mirror commented

2026-05-05 06:15:39 -06:00

Author

Owner

@rspilk commented on GitHub (Jun 22, 2023):

This issue still seems present in 2.4.0 and resolved by the same solution presented in https://github.com/debauchee/barrier/issues/500#issuecomment-559142339

@rspilk commented on GitHub (Jun 22, 2023): This issue still seems present in 2.4.0 and resolved by the same solution presented in https://github.com/debauchee/barrier/issues/500#issuecomment-559142339

gitea-mirror commented

2026-05-05 06:15:43 -06:00

Author

Owner

@200found commented on GitHub (Sep 27, 2023):

confirmed workaround still works as of 9/2023 on 2.4.0. thank you very much for this extensive solution.

@200found commented on GitHub (Sep 27, 2023): confirmed workaround still works as of 9/2023 on 2.4.0. thank you very much for this extensive solution.

gitea-mirror commented

2026-05-05 06:15:47 -06:00

Author

Owner

@rspilk commented on GitHub (Sep 27, 2023):

confirmed workaround still works as of 9/2023 on 2.4.0. thank you very much for this extensive solution.

I'm really happy to hear that. Nothing worse than finding your exact problem in a google search and seeing a response to google it.

Since this issue has been present since synergy forks I wonder if there is any ideas on how it can be addressed this late in the game. Is this too OS-Level?

@rspilk commented on GitHub (Sep 27, 2023): > confirmed workaround still works as of 9/2023 on 2.4.0. thank you very much for this extensive solution. I'm really happy to hear that. Nothing worse than finding your exact problem in a google search and seeing a response to google it. Since this issue has been present since synergy forks I wonder if there is any ideas on how it can be addressed this late in the game. Is this too OS-Level?

gitea-mirror commented

2026-05-05 06:15:50 -06:00

Author

Owner

@rspilk commented on GitHub (Sep 27, 2023):

According to the Issue on the synergy-core project: https://github.com/symless/synergy-core/issues/4041

After extensive conversation, the last comment is:

This bug is back in Windows 10 r1709. The fix that eventually worked for me was to remove the "Run in compatibility mode for: Windows 7" setting on synergys.exe. Unfortunately the configuration tool forces this setting back on any time you open it.

I don't know if it is fixable

@rspilk commented on GitHub (Sep 27, 2023): According to the Issue on the synergy-core project: https://github.com/symless/synergy-core/issues/4041 After extensive conversation, the last comment is: >This bug is back in Windows 10 r1709. The fix that eventually worked for me was to remove the "Run in compatibility mode for: Windows 7" setting on synergys.exe. Unfortunately the configuration tool forces this setting back on any time you open it. I don't know if it is fixable

Rows
Columns

[GH-ISSUE #500] Mouse sticking to upper left of screen on client device, constant up/left velocity on mouse? #389

Operating Systems

Barrier Version

Steps to reproduce bug

Other info