github-starred/barrier

Fork 0

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

[GH-ISSUE #791] Crosshair locks up when cursor hits edge of screen in Minecraft on client #627

New issue

Open

opened 2026-05-05 06:48:17 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:48:17 -06:00

Owner

Originally created by @arjf on GitHub (Jul 11, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/791

Operating Systems

Server: Ubuntu 20.04 LTS
Clients: MacOS Catalina 10.15 , Windows 10 1903

Barrier Version

Server - Snapshot 5 June 2.3.2-snapshot-210c2b70
Mac Client - Release 10 July 2.3.2-Release-5c512bf2
Windows Client - Snapshot 14 June 2.3.2-snapshot-2393393b

Steps to reproduce bug

Basically im playing minecraft on the mac client and have locked the cursor to the screen but when i move the mouse alot the cursor hits the edges, and the crosshair in the game locks up. This prevents me from properly aiming in the game.

Other info

When did the problem start to occur? When I move my crosshair alot in a particular direction which happens often as i play on a low sensitivity
Is there a way to work around it? Not that i know off
Does this bug prevent you from using Barrier entirely? No, my main use for barrier is not gaming

Originally created by @arjf on GitHub (Jul 11, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/791 ### Operating Systems ### Server: Ubuntu 20.04 LTS Clients: MacOS Catalina 10.15 , Windows 10 1903 ### Barrier Version ### Server - Snapshot 5 June 2.3.2-snapshot-210c2b70 Mac Client - Release 10 July 2.3.2-Release-5c512bf2 Windows Client - Snapshot 14 June 2.3.2-snapshot-2393393b ### Steps to reproduce bug ### Basically im playing minecraft on the mac client and have locked the cursor to the screen but when i move the mouse alot the cursor hits the edges, and the crosshair in the game locks up. This prevents me from properly aiming in the game. ### Other info ### * When did the problem start to occur? When I move my crosshair alot in a particular direction which happens often as i play on a low sensitivity * Is there a way to work around it? Not that i know off * Does this bug prevent you from using Barrier entirely? No, my main use for barrier is not gaming

gitea-mirror added the

doc

label 2026-05-05 06:48:17 -06:00

gitea-mirror commented

2026-05-05 06:48:20 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 18, 2020):

This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions[bot] commented on GitHub (Sep 18, 2020): This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.

gitea-mirror commented

2026-05-05 06:48:22 -06:00

Author

Owner

@Deelight-fr commented on GitHub (Nov 6, 2020):

Same problem for me.
Linux Server, Windows client, mouse locked on Windows.

When I play a first person game on Windows, I am unable to rotate indefinitely by continuously moving the mouse to the left or right. At a point it stops as if an invisible cursor was hitting the edge of the screen.

@Deelight-fr commented on GitHub (Nov 6, 2020): Same problem for me. Linux Server, Windows client, mouse locked on Windows. When I play a first person game on Windows, I am unable to rotate indefinitely by continuously moving the mouse to the left or right. At a point it stops as if an invisible cursor was hitting the edge of the screen.

gitea-mirror commented

2026-05-05 06:48:23 -06:00

Author

Owner

@Deelight-fr commented on GitHub (Nov 7, 2020):

I finally solved it.

RelativeMouseMoves has to be enabled (true), and the mouse pointer should be locked on the game screen (using the scroll-lock key, or a user defined shortcut). My problem was that an another barrier process was alredy running, and all config changes where ignored. Killing and relaunching the barrier server solved it.

@Deelight-fr commented on GitHub (Nov 7, 2020): I finally solved it. RelativeMouseMoves has to be enabled (true), and the mouse pointer should be locked on the game screen (using the scroll-lock key, or a user defined shortcut). My problem was that an another barrier process was alredy running, and all config changes where ignored. Killing and relaunching the barrier server solved it.

gitea-mirror commented

2026-05-05 06:48:25 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

Let's not close valid bug reports.

@p12tic commented on GitHub (Jan 10, 2021): Let's not close valid bug reports.

gitea-mirror commented

2026-05-05 06:48:26 -06:00

Author

Owner

@p12tic commented on GitHub (Jan 10, 2021):

We should have this workaround somewhere in the documentation:

RelativeMouseMoves has to be enabled (true), and the mouse pointer should be locked on the game screen (using the scroll-lock key, or a user defined shortcut). My problem was that an another barrier process was alredy running, and all config changes where ignored. Killing and relaunching the barrier server solved it.

@p12tic commented on GitHub (Jan 10, 2021): We should have this workaround somewhere in the documentation: ``` RelativeMouseMoves has to be enabled (true), and the mouse pointer should be locked on the game screen (using the scroll-lock key, or a user defined shortcut). My problem was that an another barrier process was alredy running, and all config changes where ignored. Killing and relaunching the barrier server solved it. ```

No labels

Rows
Columns