github-starred/barrier

Fork 0

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

[GH-ISSUE #164] Mouse is too sensitive in games on client #132

New issue

Open

opened 2026-05-05 05:20:45 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 05:20:45 -06:00

Owner

Originally created by @HereInPlainSight on GitHub (Oct 24, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/164

Operating Systems

Server: Linux (Gentoo)

Client: Linux (Gentoo)

(Note that this issue also existed on a Windows 7 and Gentoo Linux machine configured in either direction, but that was with synergy-core.)

Barrier Version

2.2.0-snapshot-65172ebd on both server and client.

Steps to reproduce bug

Open a game on client machine (Confirmed with LotRO, WoW, Minecraft, since this seems like synergy-core's bug #2631 there's probably a great deal more).
If the mouse is not locked to the screen, use the mouse to look around (keyboard is unaffected).

Other info

When did the problem start to occur? I have never known it not to exist.
Is there a way to work around it? Yes, if you turn on 'Use relative mouse moves' in the 'Advanced server settings' area of the 'Configure Server' button -and- lock the mouse to the client (using Scroll Lock by default), you can play the game normally.
Does this bug prevent you from using Barrier entirely? No, but it -is- my primary problem as this is my primary use case.

If there's any logs / further information you'd like me to provide, I'll be happy to. This is a -very- long-standing bug in the synergy software (currently the 5th-most commented-on open issue in synergy-core's issue tracker) that I have been hopeful to see fixed for years. (It's still not fixed in Synergy 2.)

Originally created by @HereInPlainSight on GitHub (Oct 24, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/164 ### Operating Systems ### Server: Linux (Gentoo) Client: Linux (Gentoo) (Note that this issue also existed on a Windows 7 and Gentoo Linux machine configured in either direction, but that was with synergy-core.) ### Barrier Version ### 2.2.0-snapshot-65172ebd on both server and client. ### Steps to reproduce bug ### 1. Open a game on client machine (Confirmed with LotRO, WoW, Minecraft, since this seems like synergy-core's bug #2631 there's probably a great deal more). 2. If the mouse is not locked to the screen, use the mouse to look around (keyboard is unaffected). ### Other info ### * When did the problem start to occur? I have never known it not to exist. * Is there a way to work around it? Yes, if you turn on 'Use relative mouse moves' in the 'Advanced server settings' area of the 'Configure Server' button -and- lock the mouse to the client (using Scroll Lock by default), you can play the game normally. * Does this bug prevent you from using Barrier entirely? No, but it -is- my primary problem as this is my primary use case. If there's any logs / further information you'd like me to provide, I'll be happy to. This is a -very- long-standing bug in the synergy software (currently the 5th-most commented-on open issue in synergy-core's issue tracker) that I have been hopeful to see fixed for years. (It's still not fixed in Synergy 2.)

gitea-mirror commented

2026-05-05 05:20:52 -06:00

Author

Owner

@a7hybnj2 commented on GitHub (Nov 30, 2018):

Operating Systems

Server: Linux (Gentoo)

Client: Linux (Gentoo)

(Note that this issue also existed on a Windows 7 and Gentoo Linux machine configured in either direction, but that was with synergy-core.)

Barrier Version

2.2.0-snapshot-65172ebd on both server and client.

Steps to reproduce bug

Open a game on client machine (Confirmed with LotRO, WoW, Minecraft, since this seems like synergy-core's bug symless#2631 there's probably a great deal more).

If the mouse is not locked to the screen, use the mouse to look around (keyboard is unaffected).

Other info

When did the problem start to occur? I have never known it not to exist.

Is there a way to work around it? Yes, if you turn on 'Use relative mouse moves' in the 'Advanced server settings' area of the 'Configure Server' button -and- lock the mouse to the client (using Scroll Lock by default), you can play the game normally.

Does this bug prevent you from using Barrier entirely? No, but it -is- my primary problem as this is my primary use case.

If there's any logs / further information you'd like me to provide, I'll be happy to. This is a -very- long-standing bug in the synergy software (currently the 5th-most commented-on open issue in synergy-core's issue tracker) that I have been hopeful to see fixed for years. (It's still not fixed in Synergy 2.)

I am not a dev just a user:
I had this problem and checking (turning on) the box that reads "relative mouse movements" in the server options fixed it. I also added keybindings to lock cursor to current screen so it wouldn't wigout while gaming.

@a7hybnj2 commented on GitHub (Nov 30, 2018): > ### Operating Systems > Server: Linux (Gentoo) > > Client: Linux (Gentoo) > > (Note that this issue also existed on a Windows 7 and Gentoo Linux machine configured in either direction, but that was with synergy-core.) > > ### Barrier Version > 2.2.0-snapshot-65172ebd on both server and client. > > ### Steps to reproduce bug > 1. Open a game on client machine (Confirmed with LotRO, WoW, Minecraft, since this seems like synergy-core's bug [symless#2631](https://github.com/symless/synergy-core/issues/2631) there's probably a great deal more). > 2. If the mouse is not locked to the screen, use the mouse to look around (keyboard is unaffected). > > ### Other info > * When did the problem start to occur? I have never known it not to exist. > * Is there a way to work around it? Yes, if you turn on 'Use relative mouse moves' in the 'Advanced server settings' area of the 'Configure Server' button -and- lock the mouse to the client (using Scroll Lock by default), you can play the game normally. > * Does this bug prevent you from using Barrier entirely? No, but it -is- my primary problem as this is my primary use case. > > If there's any logs / further information you'd like me to provide, I'll be happy to. This is a -very- long-standing bug in the synergy software (currently the 5th-most commented-on open issue in synergy-core's issue tracker) that I have been hopeful to see fixed for years. (It's still not fixed in Synergy 2.) I am not a dev just a user: I had this problem and checking (turning on) the box that reads "relative mouse movements" in the server options fixed it. I also added keybindings to lock cursor to current screen so it wouldn't wigout while gaming.

gitea-mirror commented

2026-05-05 05:20:54 -06:00

Author

Owner

@rjdza commented on GitHub (May 21, 2020):

I am also having this issue, and have been having it since I first got Minecraft a gazillion years ago. Relative mouse movements did not have any noticeable effect for me, and never has (it's often been suggested as a solution).

Affects both Java and Bedrock editions. (As an additional FYI note, Guild Wars 2 works but is a bit erratic.)

It would be great if the devs could comment here, if only to let us know they are aware the bug exists.

@rjdza commented on GitHub (May 21, 2020): I am also having this issue, and have been having it since I first got Minecraft a gazillion years ago. Relative mouse movements did not have any noticeable effect for me, and never has (it's often been suggested as a solution). Affects both Java and Bedrock editions. (As an additional FYI note, Guild Wars 2 works but is a bit erratic.) It would be great if the devs could comment here, if only to let us know they are aware the bug exists.

gitea-mirror commented

2026-05-05 05:20:56 -06:00

Author

Owner

@anarqz commented on GitHub (Jul 4, 2020):

Hi @rjdza , try to create a keybinding like @a7hybnj2 said, so in the screen you're playing, you lock the cursor and this issue should be gone. At least it solved the issue for me.

@anarqz commented on GitHub (Jul 4, 2020): Hi @rjdza , try to create a keybinding like @a7hybnj2 said, so in the screen you're playing, you lock the cursor and this issue should be gone. At least it solved the issue for me. ![image](https://user-images.githubusercontent.com/2521595/86519793-c4498f80-be14-11ea-8c36-ac276cee4aee.png)

gitea-mirror commented

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

Author

Owner

@rjdza commented on GitHub (Aug 18, 2020):

Thanks for the suggestion. For now, though, I would prefer to use Input Director (or ShareMouse) as both work well without this issue.

For me, locking to a screen would be counter-productive, as I have a number of screens across 4 machines, and being able to move almost instantly (in minecraft and other games I have to bring up a menu or something first) from window to window without artificial limits is important.

Hi @rjdza , try to create a keybinding like @a7hybnj2 said, so in the screen you're playing, you lock the cursor and this issue should be gone. At least it solved the issue for me.

@rjdza commented on GitHub (Aug 18, 2020): Thanks for the suggestion. For now, though, I would prefer to use Input Director (or ShareMouse) as both work well without this issue. For me, locking to a screen would be counter-productive, as I have a number of screens across 4 machines, and being able to move almost instantly (in minecraft and other games I have to bring up a menu or something first) from window to window without artificial limits is important. > Hi @rjdza , try to create a keybinding like @a7hybnj2 said, so in the screen you're playing, you lock the cursor and this issue should be gone. At least it solved the issue for me.

gitea-mirror commented

2026-05-05 05:21:03 -06:00

Author

Owner

@webcleric commented on GitHub (Jul 15, 2022):

Did the same hotkey as @a7hybnj2, but it strangely did not work unless I add Use relative mouse moves , might help someone.

@webcleric commented on GitHub (Jul 15, 2022): Did the same hotkey as @a7hybnj2, but it strangely did not work unless I add _Use relative mouse moves_ , might help someone.

No labels

Rows
Columns