github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #490] Bouncing mouse at screen edge. #380

New issue

Open

opened 2026-05-05 06:14:05 -06:00 by gitea-mirror · 10 comments

gitea-mirror commented

2026-05-05 06:14:05 -06:00

Owner

Originally created by @lovelydumpling on GitHub (Nov 11, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/490

Operating Systems

Server: Windows 10 Pro 1809

Client: ubuntuMATE 18.04

Barrier Version

2.3.2

Steps to reproduce bug

Connect Linux client to the left side of Windows server.
On Windows server, move mouse to left screen edge in order to use Linux client.
Mouse moves to Linux for a split moment before bouncing back to Windows. As though it's reading itself on Linux's edge and moving it back. After enough attempts/finagling with it at different speeds, can get it to finally move onto the other screen. Problem does not happen in reverse, seamless transition from Linux to Windows, just not Windows to Linux.

Other info

When did the problem start to occur? This morning. Just started using Barrier last night, worked flawlessly. I wake up this morning and this issue persists. Restarting Barrier on both systems and restarting the systems themselves did not correct the issue.
Is there a way to work around it? With enough persistence, I can get the mouse over. It's far from seamless though.
Does this bug prevent you from using Barrier entirely? No, but it's very frustrating and confusing since this wasn't happening last night.

Edit: My hypothesis about it detecting the screen edge and immediately switching back seems to be bust. I toggled on "Switch after waiting" and the issue persists. Notably when it bounces back to Windows, half the time the Linux cursor jumps to the center of its screen.

Originally created by @lovelydumpling on GitHub (Nov 11, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/490 ### Operating Systems ### Server: Windows 10 Pro 1809 Client: ubuntuMATE 18.04 ### Barrier Version ### 2.3.2 ### Steps to reproduce bug ### 1. Connect Linux client to the left side of Windows server. 2. On Windows server, move mouse to left screen edge in order to use Linux client. 3. Mouse moves to Linux for a split moment before bouncing back to Windows. As though it's reading itself on Linux's edge and moving it back. After enough attempts/finagling with it at different speeds, can get it to finally move onto the other screen. Problem does not happen in reverse, seamless transition from Linux to Windows, just not Windows to Linux. ### Other info ### * When did the problem start to occur? This morning. Just started using Barrier last night, worked flawlessly. I wake up this morning and this issue persists. Restarting Barrier on both systems and restarting the systems themselves did not correct the issue. * Is there a way to work around it? With enough persistence, I can get the mouse over. It's far from seamless though. * Does this bug prevent you from using Barrier entirely? No, but it's very frustrating and confusing since this wasn't happening last night. Edit: My hypothesis about it detecting the screen edge and immediately switching back seems to be bust. I toggled on "Switch after waiting" and the issue persists. Notably when it bounces back to Windows, half the time the Linux cursor jumps to the center of its screen.

gitea-mirror added the

bug

windows

linux

labels 2026-05-05 06:14:05 -06:00

gitea-mirror commented

2026-05-05 06:14:08 -06:00

Author

Owner

@ArchitectNate commented on GitHub (Jul 9, 2020):

I am experiencing the same.

Barrier Version: 2.3.2

Windows 10 Home (Server) on the left and Ubuntu 20.04 LTS (Client) on the right

If I move the mouse to the edge of the Windows 10 screen and stop, the mouse will switch screens without any issues, and then I can continue to move the mouse on Linux.

If I try to continuously move to the right as I pass from Windows to Linux, the mouse will get "trapped" on the edge. It behaves as if it is constantly re-triggering the move from Windows to Linux and thus constantly placing the mouse at the left edge of my Linux screen where the crossover happened.

As a note, it generally is less of an issue if the mouse is very quickly or very slowly. You can see it still will sometimes hover on the edge for a moment, but it will break away.

Moving at a moderate (normal) speed, it tends to get trapped for a second plus, or, never crosses over at all.

I am currently using "Switch After Waiting" set 10ms to mitigate the problem (But 100ms and 250ms worked with varying degrees of success as well). @lovelydumpling mentioned that that didn't work for them. It does mostly work for me. I can still see that it wants to get trapped, but, it doesn't get trapped for an extended period of time.

So it's a good work around for now.

@ArchitectNate commented on GitHub (Jul 9, 2020): I am experiencing the same. Barrier Version: 2.3.2 Windows 10 Home (Server) on the left and Ubuntu 20.04 LTS (Client) on the right If I move the mouse to the edge of the Windows 10 screen and stop, the mouse will switch screens without any issues, and then I can continue to move the mouse on Linux. If I try to continuously move to the right as I pass from Windows to Linux, the mouse will get "trapped" on the edge. It behaves as if it is constantly re-triggering the move from Windows to Linux and thus constantly placing the mouse at the left edge of my Linux screen where the crossover happened. As a note, it generally is less of an issue if the mouse is very quickly or very slowly. You can see it still will sometimes hover on the edge for a moment, but it will break away. Moving at a moderate (normal) speed, it tends to get trapped for a second plus, or, never crosses over at all. I am currently using "Switch After Waiting" set 10ms to mitigate the problem (But 100ms and 250ms worked with varying degrees of success as well). @lovelydumpling mentioned that that didn't work for them. It does mostly work for me. I can still see that it wants to get trapped, but, it doesn't get trapped for an extended period of time. So it's a good work around for now.

gitea-mirror commented

2026-05-05 06:14:10 -06:00

Author

Owner

@D0ot commented on GitHub (Sep 3, 2020):

experienceing the same.

Barrier Version 2.3.3

Server: Windows 10 Pro
Client: Windows 10 Eduction

some logs:

[2020-09-03T19:53:32] INFO: switch from "2600x" to "2500u" at 1919,523
[2020-09-03T19:53:32] INFO: leaving screen
[2020-09-03T19:53:32] INFO: switch from "2500u" to "2600x" at 7,698
[2020-09-03T19:53:32] INFO: entering screen
[2020-09-03T19:53:32] INFO: switch from "2600x" to "2500u" at 1919,523
[2020-09-03T19:53:32] INFO: leaving screen
[2020-09-03T19:53:32] INFO: switch from "2500u" to "2600x" at 7,696
[2020-09-03T19:53:32] INFO: entering screen
[2020-09-03T19:53:32] INFO: switch from "2600x" to "2500u" at 1919,522
[2020-09-03T19:53:32] INFO: leaving screen
[2020-09-03T19:53:34] INFO: switch from "2500u" to "2600x" at 2,786
[2020-09-03T19:53:34] INFO: entering screen

the only operation I did is just move the cursor from "2600x" to "2500u" and move it back, but the screen switches 5 times...

if I try to move cursor to "2500u" from "2600x" at a super high speed, the switch time could be above 20, looks like the cursor is bouncing at the scrren edge.

@D0ot commented on GitHub (Sep 3, 2020): experienceing the same. Barrier Version 2.3.3 Server: Windows 10 Pro Client: Windows 10 Eduction some logs: ``` [2020-09-03T19:53:32] INFO: switch from "2600x" to "2500u" at 1919,523 [2020-09-03T19:53:32] INFO: leaving screen [2020-09-03T19:53:32] INFO: switch from "2500u" to "2600x" at 7,698 [2020-09-03T19:53:32] INFO: entering screen [2020-09-03T19:53:32] INFO: switch from "2600x" to "2500u" at 1919,523 [2020-09-03T19:53:32] INFO: leaving screen [2020-09-03T19:53:32] INFO: switch from "2500u" to "2600x" at 7,696 [2020-09-03T19:53:32] INFO: entering screen [2020-09-03T19:53:32] INFO: switch from "2600x" to "2500u" at 1919,522 [2020-09-03T19:53:32] INFO: leaving screen [2020-09-03T19:53:34] INFO: switch from "2500u" to "2600x" at 2,786 [2020-09-03T19:53:34] INFO: entering screen ``` the only operation I did is just move the cursor from "2600x" to "2500u" and move it back, but the screen switches 5 times... if I try to move cursor to "2500u" from "2600x" at a super high speed, the switch time could be above 20, looks like the cursor is bouncing at the scrren edge.

gitea-mirror commented

2026-05-05 06:14:12 -06:00

Author

Owner

@exhuma commented on GitHub (May 9, 2021):

I'm experiencing the same on a windows/windows setup. So I don't think this is purely a Linux issue. I have two Windows boxes and two Linux boxes and I have the issue between all setups. To be clear, the host is Windows, then I have 3 clients (2xLinux and 1xWindows).

@exhuma commented on GitHub (May 9, 2021): I'm experiencing the same on a windows/windows setup. So I don't think this is purely a Linux issue. I have two Windows boxes and two Linux boxes and I have the issue between all setups. To be clear, the host is Windows, then I have 3 clients (2xLinux and 1xWindows).

gitea-mirror commented

2026-05-05 06:14:14 -06:00

Author

Owner

@vitaminmoo commented on GitHub (Nov 2, 2021):

Try setting your mouse's polling rate down to 125hz - I have this issue if it's set to 250hz or above.

@vitaminmoo commented on GitHub (Nov 2, 2021): Try setting your mouse's polling rate down to 125hz - I have this issue if it's set to 250hz or above.

gitea-mirror commented

2026-05-05 06:14:17 -06:00

Author

Owner

@exhuma commented on GitHub (Nov 2, 2021):

@vitaminmoo is that a client or server setting? I can't find it anywhere

@exhuma commented on GitHub (Nov 2, 2021): @vitaminmoo is that a client or server setting? I can't find it anywhere

gitea-mirror commented

2026-05-05 06:14:19 -06:00

Author

Owner

@barba3 commented on GitHub (Apr 11, 2022):

I am reproducing this bug on Windows 11 + MacOS Monterey 12.3.1.
Windows 11 is server. MacOS is client.
Barrier 2.4.0-release-3e0d758b on both machines.

The bounciness increases when the Windows machine slows down with CPU and memory intensive tasks.

@barba3 commented on GitHub (Apr 11, 2022): I am reproducing this bug on Windows 11 + MacOS Monterey 12.3.1. Windows 11 is server. MacOS is client. Barrier 2.4.0-release-3e0d758b on both machines. The bounciness increases when the Windows machine slows down with CPU and memory intensive tasks.

gitea-mirror commented

2026-05-05 06:14:21 -06:00

Author

Owner

@vitaminmoo commented on GitHub (Jun 2, 2022):

@exhuma it's a mouse setting - If you're using a Logitech mouse it's in the G HUB software

@vitaminmoo commented on GitHub (Jun 2, 2022): @exhuma it's a mouse setting - If you're using a Logitech mouse it's in the G HUB software

gitea-mirror commented

2026-05-05 06:14:23 -06:00

Author

Owner

@Jacksper13 commented on GitHub (Aug 29, 2022):

I have the same issue on win 10 server + ubuntu 20.04lts, barrier 2.4.0 on both machines.

The mouse setting dind't do anything for me, but found the solution in here: https://github.com/debauchee/barrier/issues/206#issuecomment-464136943

The display scaling on windows 10 server was messing with this. Just changed it to 100% and that fixed the issue (right click on desktop, screen config, set to 100%)

@Jacksper13 commented on GitHub (Aug 29, 2022): I have the same issue on win 10 server + ubuntu 20.04lts, barrier 2.4.0 on both machines. The mouse setting dind't do anything for me, but found the solution in here: https://github.com/debauchee/barrier/issues/206#issuecomment-464136943 The display scaling on windows 10 server was messing with this. Just changed it to 100% and that fixed the issue (right click on desktop, screen config, set to 100%)

gitea-mirror commented

2026-05-05 06:14:25 -06:00

Author

Owner

@FLeiXiuS commented on GitHub (Oct 12, 2022):

Confirmed setting my polling rate <= 250ms resolved this issue for me.

@FLeiXiuS commented on GitHub (Oct 12, 2022): Confirmed setting my polling rate <= 250ms resolved this issue for me.

gitea-mirror commented

2026-05-05 06:14:26 -06:00

Author

Owner

@V3ntus commented on GitHub (Jan 24, 2023):

Setting the polling worked using a Razer Viper Mini on a Windows 11 21H2 host (Barrier 2.3.3 release 3395cca9) with a Mac Monterey client (Barrier 2.4.0 release 3e0d758b). Had it set to 1000Hz, setting to 125Hz worked.

@V3ntus commented on GitHub (Jan 24, 2023): Setting the polling worked using a Razer Viper Mini on a Windows 11 21H2 host (Barrier 2.3.3 release 3395cca9) with a Mac Monterey client (Barrier 2.4.0 release 3e0d758b). Had it set to 1000Hz, setting to 125Hz worked.

No labels

Rows
Columns