github-starred/barrier

Fork 0

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

[GH-ISSUE #379] Mouse offset bug #298

New issue

Open

opened 2026-05-05 05:59:11 -06:00 by gitea-mirror · 2 comments

gitea-mirror commented

2026-05-05 05:59:11 -06:00

Owner

Originally created by @wjtk4444 on GitHub (Jul 28, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/379

Operating Systems

Server: Arch Linux

Client: Windows 7, Windows 10 (various editions, various compilation numbers)

There's a high possibility that the bug is platform independent, at the very least it seems to occur on any X11 host and any Windows client.

Barrier Version

2.1.2-2 server
2.2 and 2.3 client

The bug should be present on any version

Steps to reproduce bug

Lock cursor to any screen (client or host) while it's not perfectly in the middle of the client screen (client screen doesn't have to be focused, the last cursor position that barrier remembers matters).
Start any fullscreen application on client (ie. any game)
Switch back and forth between the screens

Expected behaviour

Cursor moves between screens as when not locked

Actual behaviour

Cursor moves between screens and moves the in-game camera by a certain offset, for example:

switch to the other screen, camera rotates left
switch back to the screen with game running, camera rotates right (goes back to it's position before switching "away")

NOTE

It does happen anywhere, not just in the fullscreen applications, but it's hard to notice it unless the cursor movement moves the camera or something else. If my explanation what happens is not clear enough - I can record a video of the bug happening.

Workaround

Lock cursor to the screen (any screen)
Unlock cursor on client (causes the cursor to move to the exact middle of the screen)
Lock cursor again without moving it a single pixel on client (lock can be done on any screen, you can move cursor freely on host)

This seems to fix the issue, but is quite annoying to do every single time.

Steps to fix the problem

When locking cursor to the screen, move it to the center of the screen beforehand.

I'm not familiar with the codebase, but I expect it to be a one-liner or something similar.

screen.moveCursor(screen.width / 2, screen.height / 2);

To prevent this issue from occuring under any circumstances, I think that the client position should be set to the screen middle when locking even if mouse is currently on another screen. So, perhaps something like this instead:

for (Screen screen : clients)
    screen.setLastCursorPosition(screen.width / 2, screen.height / 2);

Additional notes

One could try checking if it only occurs on Windows or not and add some conditions before moving the cursor (might not be necessary on other systems or reverse configurations - Windows host and Linux guest). I don't think it's necessary though, locking/unlocking doesn't happen too often and I personally won't be bothered if it resets cursor position on all screens.

Also, can we please get https://github.com/debauchee/barrier/issues/187 done? It probably needs a little more work (adding a checkbox and a config flag) but it would be awesome to have in addition to fixing the offset bug.

Originally created by @wjtk4444 on GitHub (Jul 28, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/379 ### Operating Systems ### Server: Arch Linux Client: Windows 7, Windows 10 (various editions, various compilation numbers) There's a high possibility that the bug is platform independent, at the very least it seems to occur on any X11 host and any Windows client. ### Barrier Version ### 2.1.2-2 server 2.2 and 2.3 client The bug should be present on any version ### Steps to reproduce bug ### 1. Lock cursor to any screen (client or host) while it's not perfectly in the middle of the client screen (client screen doesn't have to be focused, the last cursor position that barrier remembers matters). 2. Start any fullscreen application on client (ie. any game) 3. Switch back and forth between the screens #### Expected behaviour #### Cursor moves between screens as when not locked #### Actual behaviour #### Cursor moves between screens and moves the in-game camera by a certain offset, for example: 1. switch to the other screen, camera rotates left 2. switch back to the screen with game running, camera rotates right (goes back to it's position before switching "away") #### NOTE #### It does happen anywhere, not just in the fullscreen applications, but it's hard to notice it unless the cursor movement moves the camera or something else. If my explanation what happens is not clear enough - I can record a video of the bug happening. ### Workaround ### 1. Lock cursor to the screen (any screen) 2. Unlock cursor on client (causes the cursor to move to the exact middle of the screen) 3. Lock cursor again without moving it a single pixel on client (lock can be done on any screen, you can move cursor freely on host) This seems to fix the issue, but is quite annoying to do every single time. ### Steps to fix the problem ### 1. When locking cursor to the screen, move it to the center of the screen beforehand. I'm not familiar with the codebase, but I expect it to be a one-liner or something similar. `screen.moveCursor(screen.width / 2, screen.height / 2);` To prevent this issue from occuring under any circumstances, I think that the client position should be set to the screen middle when locking even if mouse is currently on another screen. So, perhaps something like this instead: ``` for (Screen screen : clients) screen.setLastCursorPosition(screen.width / 2, screen.height / 2); ``` ### Additional notes ### One could try checking if it only occurs on Windows or not and add some conditions before moving the cursor (might not be necessary on other systems or reverse configurations - Windows host and Linux guest). I don't think it's necessary though, locking/unlocking doesn't happen too often and I personally won't be bothered if it resets cursor position on all screens. Also, can we please get https://github.com/debauchee/barrier/issues/187 done? It probably needs a little more work (adding a checkbox and a config flag) but it would be awesome to have in addition to fixing the offset bug.

gitea-mirror added the

bug

windows

linux

labels 2026-05-05 05:59:11 -06:00

gitea-mirror commented

2026-05-05 05:59:15 -06:00

Author

Owner

@upgrayedd22 commented on GitHub (Aug 7, 2019):

I think that I have this issue, too. Mac (Mojave) 10.14.6 is server. Laptop (Windows 2012 server) is client. When I move the cursor off screen to the PC, the Windows cursor seems to pull to the top-left. On my Mac's screen, I can see the pointer directly in the middle of the screen, while I move the cursor on the PC, simultaneously.

The way I was able to test the "pulling" was by moving the server mouse in tiny circles. I tried the workaround offerred by wjtk4444, but I cannot seem to get the hotkeys to work.

I have a razor keyboard and mouse plugged in. When I use the Mac's touch pad in Windows, it does not seem to be affected by the "pulling".

@upgrayedd22 commented on GitHub (Aug 7, 2019): I think that I have this issue, too. Mac (Mojave) 10.14.6 is server. Laptop (Windows 2012 server) is client. When I move the cursor off screen to the PC, the Windows cursor seems to pull to the top-left. On my Mac's screen, I can see the pointer directly in the middle of the screen, while I move the cursor on the PC, simultaneously. The way I was able to test the "pulling" was by moving the server mouse in tiny circles. I tried the workaround offerred by wjtk4444, but I cannot seem to get the hotkeys to work. I have a razor keyboard and mouse plugged in. When I use the Mac's touch pad in Windows, it does not seem to be affected by the "pulling".

gitea-mirror commented

2026-05-05 05:59:18 -06:00

Author

Owner

@iaian7 commented on GitHub (Aug 23, 2019):

Same bug between a Mac Pro and a MacBook Pro running MacOS 10.13.6 (server) and MacOS 10.14.6 (client). The mouse moves much faster toward the upper left, so it's very difficult to use. Moving the mouse in a circle displays this error really well. Same bug prevented me from using Synergy too.

@iaian7 commented on GitHub (Aug 23, 2019): Same bug between a Mac Pro and a MacBook Pro running MacOS 10.13.6 (server) and MacOS 10.14.6 (client). The mouse moves much faster toward the upper left, so it's very difficult to use. Moving the mouse in a circle displays this error really well. Same bug prevented me from using Synergy too.

gitea-mirror referenced this issue

2026-05-05 07:59:14 -06:00

[PR #679] [MERGED] XWindowsEventQueueBuffer: Fix delays when waiting for new events #1674