Barrier: Mouse is too sensitive in games on client

Created on 25 Oct 2018  ·  4Comments  ·  Source: debauchee/barrier

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.)

Most helpful comment

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 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.

All 4 comments

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 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.

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.

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

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.

Was this page helpful?
0 / 5 - 0 ratings