github-starred/barrier

Fork 0

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

[GH-ISSUE #453] Mouse Focus Lost When Captive Mouse Accelerates Towards Borders #354

New issue

Open

opened 2026-05-05 06:06:37 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

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

Owner

Originally created by @AnotherJellyfish on GitHub (Oct 6, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/453

Operating Systems

Server: Windows 10 1903

Client: Manjaro Linux

Barrier Version

2.3.2-snapshot-210c2b70

Steps to reproduce bug

Set (almost) any game to fullscreen or borderless window or windowed (close to the Barrier border). When moving mouse extremely fast in the direction of any edge associated with barrier, the mouse will break out of the captive program (first person shooters for instance) into the other monitor. I'm assuming this would happen with any program that has the mouse captive, although I can think of none to test.

Other info

Problem occurs on almost any fullscreen game I play except for some exceptions. Games where it occurs include Dirty Bomb, Insurgency Sandstorm, and Borderlands 3. An exception includes Overwatch.

Is there a way to work around it?
Yes. Play the games in a window small enough so that moving the mouse towards the barriers can't reach the other monitor. This can depend on mouse dpi and sensitivity. With my sensitivity settings 1820 horizontal window width is a sweet spot where it doesn't occur, but if I move my mouse faster than I ever do while gaming it can still leave the captive window.
The other easy workaround is to use scroll lock to lock Barrier to the gaming window and toggle it every time you want to go to the other screen while gaming.
Does this bug prevent you from using Barrier entirely? No.

Originally created by @AnotherJellyfish on GitHub (Oct 6, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/453 ### Operating Systems ### Server: Windows 10 1903 Client: Manjaro Linux ### Barrier Version ### 2.3.2-snapshot-210c2b70 ### Steps to reproduce bug ### Set (almost) any game to fullscreen or borderless window or windowed (close to the Barrier border). When moving mouse extremely fast in the direction of any edge associated with barrier, the mouse will break out of the captive program (first person shooters for instance) into the other monitor. I'm assuming this would happen with any program that has the mouse captive, although I can think of none to test. ### Other info ### Problem occurs on almost any fullscreen game I play except for some exceptions. Games where it occurs include Dirty Bomb, Insurgency Sandstorm, and Borderlands 3. An exception includes Overwatch. * Is there a way to work around it? Yes. Play the games in a window small enough so that moving the mouse towards the barriers can't reach the other monitor. This can depend on mouse dpi and sensitivity. With my sensitivity settings 1820 horizontal window width is a sweet spot where it doesn't occur, but if I move my mouse faster than I ever do while gaming it can still leave the captive window. The other easy workaround is to use scroll lock to lock Barrier to the gaming window and toggle it every time you want to go to the other screen while gaming. * Does this bug prevent you from using Barrier entirely? No.

gitea-mirror added the

windows

linux

labels 2026-05-05 06:06:37 -06:00

gitea-mirror commented

2026-05-05 06:06:41 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Oct 6, 2019):

I think if you enable scroll lock, the mouse will be locked to a single system.

@AdrianKoshka commented on GitHub (Oct 6, 2019): I think if you enable scroll lock, the mouse will be locked to a single system.

gitea-mirror commented

2026-05-05 06:06:44 -06:00

Author

Owner

@AnotherJellyfish commented on GitHub (Oct 6, 2019):

I think if you enable scroll lock, the mouse will be locked to a single system.

Yes I spoke about this in my "other info" section. It's a workaround to the problem but not an outright fix.

@AnotherJellyfish commented on GitHub (Oct 6, 2019): > > > I think if you enable scroll lock, the mouse will be locked to a single system. Yes I spoke about this in my "other info" section. It's a workaround to the problem but not an outright fix.

gitea-mirror commented

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

Author

Owner

@AdrianKoshka commented on GitHub (Oct 6, 2019):

I don't see how it's not an outright fix, it's how synergy was designed.

On Sun, Oct 6, 2019 at 5:44 PM AnotherJellyfish notifications@github.com
wrote:

I think if you enable scroll lock, the mouse will be locked to a single
system.

Yes I spoke about this in my "other info" section. It's a workaround to
the problem but not an outright fix.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/debauchee/barrier/issues/453?email_source=notifications&email_token=ACCJUT462YIGNVZMX7PFKDTQNJL5PA5CNFSM4I55IXNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOUZ7A#issuecomment-538791164,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACCJUT76GFMPKU34DXSEH4LQNJL5PANCNFSM4I55IXNA
.

@AdrianKoshka commented on GitHub (Oct 6, 2019): I don't see how it's not an outright fix, it's how synergy was designed. On Sun, Oct 6, 2019 at 5:44 PM AnotherJellyfish <notifications@github.com> wrote: > I think if you enable scroll lock, the mouse will be locked to a single > system. > > Yes I spoke about this in my "other info" section. It's a workaround to > the problem but not an outright fix. > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub > <https://github.com/debauchee/barrier/issues/453?email_source=notifications&email_token=ACCJUT462YIGNVZMX7PFKDTQNJL5PA5CNFSM4I55IXNKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAOUZ7A#issuecomment-538791164>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ACCJUT76GFMPKU34DXSEH4LQNJL5PANCNFSM4I55IXNA> > . >

gitea-mirror commented

2026-05-05 06:06:51 -06:00

Author

Owner

@AnotherJellyfish commented on GitHub (Oct 6, 2019):

I don't see how it's not an outright fix, it's how synergy was designed.
…
On Sun, Oct 6, 2019 at 5:44 PM AnotherJellyfish @.***> wrote: I think if you enable scroll lock, the mouse will be locked to a single system. Yes I spoke about this in my "other info" section. It's a workaround to the problem but not an outright fix.

I've had no such issues with synergy, or perhaps you're misunderstanding my issue? I only switched to debauchee because it had a version on the aur repository that is consistently updated not because I have the same problem with that piece of software.

To rephrase the issue: With synergy if the mouse is captive to a window, it will never leave that captive window. At least when I used it with Windows 10 + Ubuntu. Eg. if you're playing a first person shooter, and your "Barrier" monitor is to the right, and you turn too far to the right, your mouse will escape the captive window and move to the other monitor. This doesn't seem to be the intended behavior, and if it is, then call this a feature request! This issue makes many types of games and software extremely annoying to use. Not unusable, but very frustrating.

@AnotherJellyfish commented on GitHub (Oct 6, 2019): > I don't see how it's not an outright fix, it's how synergy was designed. > […](#) > On Sun, Oct 6, 2019 at 5:44 PM AnotherJellyfish ***@***.***> wrote: I think if you enable scroll lock, the mouse will be locked to a single system. Yes I spoke about this in my "other info" section. It's a workaround to the problem but not an outright fix. I've had no such issues with synergy, or perhaps you're misunderstanding my issue? I only switched to debauchee because it had a version on the aur repository that is consistently updated not because I have the same problem with that piece of software. To rephrase the issue: With synergy if the mouse is captive to a window, it will never leave that captive window. At least when I used it with Windows 10 + Ubuntu. Eg. if you're playing a first person shooter, and your "Barrier" monitor is to the right, and you turn too far to the right, your mouse will escape the captive window and move to the other monitor. This doesn't seem to be the intended behavior, and *if it is*, then call this a feature request! This issue makes many types of games and software extremely annoying to use. Not unusable, but very frustrating.

gitea-mirror commented

2026-05-05 06:06:53 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 2, 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 2, 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:06:55 -06:00

Author

Owner

@tobozo commented on GitHub (May 21, 2021):

bump

problem still exists in many games today, adding "Space Engineers" to the list

@tobozo commented on GitHub (May 21, 2021): bump problem still exists in many games today, adding "Space Engineers" to the list

gitea-mirror commented

2026-05-05 06:06:57 -06:00

Author

Owner

@ImGGAAVVIINN commented on GitHub (Jul 4, 2024):

Happens in Minecraft Java Edition On both Windows and Linux (Ubuntu 20.04, KDE Plasma 5)

@ImGGAAVVIINN commented on GitHub (Jul 4, 2024): Happens in Minecraft Java Edition On both Windows and Linux (Ubuntu 20.04, KDE Plasma 5)

gitea-mirror referenced this issue

2026-05-05 07:57:32 -06:00

[PR #355] [CLOSED] Build with Inno Setup 6 #1608