github-starred/barrier

Fork 0

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

bottom of monitor on clients #452

New issue

Open

opened 2026-05-05 06:25:34 -06:00 by gitea-mirror · 9 comments

gitea-mirror commented

2026-05-05 06:25:34 -06:00

Owner

Originally created by @jaxjexjox on GitHub (Feb 23, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/573

Operating Systems

Windows 10 / Windows 7.
Barrier latest x64 build as of post date.

When using the remote system (The one I'm literally typing this on now) if I mouse towards the top or bottom of the display (sides of the monitor which do NOT connect to other displays) the mouse 'sticks' there and needs to be pulled down a bit more than normal. It's quite weird and annoying.

I've rebooted obviously many timers -i t's been like this for a few months.

Is there a settinhg I can check that would cause this?

Originally created by @jaxjexjox on GitHub (Feb 23, 2020). Original GitHub issue: https://github.com/debauchee/barrier/issues/573 ### Operating Systems ### Windows 10 / Windows 7. Barrier latest x64 build as of post date. When using the remote system (The one I'm literally typing this on now) if I mouse towards the top or bottom of the display (sides of the monitor which do NOT connect to other displays) the mouse 'sticks' there and needs to be pulled down a bit more than normal. It's quite weird and annoying. I've rebooted obviously many timers -i t's been like this for a few months. Is there a settinhg I can check that would cause this?

gitea-mirror commented

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

Author

Owner

@the-wes commented on GitHub (Mar 1, 2020):

Does your client (remote system) have multiple monitors configured in its Display properties? Even if they are not in use, if there is one configured which has a higher height than the one you're looking at, it can create the phenomenon you are describing. There may also be other causes, but this is a good one to check first.

@the-wes commented on GitHub (Mar 1, 2020): Does your client (remote system) have multiple monitors configured in its Display properties? Even if they are not in use, if there is one configured which has a higher height than the one you're looking at, it can create the phenomenon you are describing. There may also be other causes, but this is a good one to check first.

gitea-mirror commented

2026-05-05 06:25:39 -06:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 28, 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 28, 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:25:42 -06:00

Author

Owner

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

Since there was no response, we can assume that the issue was likely the one pointed to by the-wes. Therefore, I'm closing the issue.

@p12tic commented on GitHub (Jan 10, 2021): Since there was no response, we can assume that the issue was likely the one pointed to by `the-wes`. Therefore, I'm closing the issue.

gitea-mirror commented

2026-05-05 06:25:45 -06:00

Author

Owner

@twpol commented on GitHub (May 3, 2021):

I am pretty sure I am experiencing the annoyance in https://github.com/debauchee/barrier/issues/573#issuecomment-593062014, but can't find any other references - should I open a new issue (it is very annoying behaviour) or is it considered a wont-fix?

@twpol commented on GitHub (May 3, 2021): I am pretty sure I am experiencing the annoyance in https://github.com/debauchee/barrier/issues/573#issuecomment-593062014, but can't find any other references - should I open a new issue (it is very annoying behaviour) or is it considered a wont-fix?

gitea-mirror commented

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

Author

Owner

@the-wes commented on GitHub (May 3, 2021):

I'll reopen this one so you can contribute if you wish.

@the-wes commented on GitHub (May 3, 2021): I'll reopen this one so you can contribute if you wish.

gitea-mirror commented

2026-05-05 06:25:50 -06:00

Author

Owner

@twpol commented on GitHub (May 3, 2021):

Server
Operating system: Windows 10 20H2 (latest)
Software: Barrier 2.3.3 (latest)
Software configuration:

section: links
	SERVER:
		right = CLIENT
	CLIENT:
		left = SERVER
end

Monitor configuration:

Virtual Desktop:                             
  (0, -439) - (4000, 2121)                   
                                             
Display Monitors:                            
  \\.\DISPLAY1 [primary]                     
    (0, 0) - (2560, 1440) [display]          
    (0, 0) - (2560, 1400) [work area]        
  \\.\DISPLAY2                               
    (2560, -439) - (4000, 2121) [display]    
    (2560, -439) - (4000, 2081) [work area]

Client
Operating system: Windows 10 20H2 (latest)
Software: Barrier 2.3.3 (latest)
Monitor configuration:

Virtual Desktop:
  (0, -474) - (6256, 2086)

Display Monitors:
  \\.\DISPLAY1
    (2256, 72) - (4816, 1512) [display]
    (2256, 72) - (4816, 1472) [work area]
  \\.\DISPLAY2 [primary]
    (0, 0) - (1504, 1003) [display]
    (0, 0) - (1504, 963) [work area]
  \\.\DISPLAY3
    (4816, -474) - (6256, 2086) [display]
    (4816, -474) - (6256, 2046) [work area]

Issue
Almost certainly because the bounding box of the client monitors includes dead space (where no monitor area exists), the mouse can virtually move off the top and bottom edges of the primary monitor on the client and will take an equal amount of reverse movement to return (unless it has hit the bounding box).

This is super annoying, especially as the client's mouse visually appears at the edge of the monitor even though Barrier's virtual position is way off the edge.

The only way I've found to fix the sticky mouse is to enable relativeMouseMoves and turn on lockCursorToScreen. This is also what is required to make mouse control work in some games, so it's not entirely surprising it changes the behaviour here.

@twpol commented on GitHub (May 3, 2021): **Server** Operating system: Windows 10 20H2 (latest) Software: Barrier 2.3.3 (latest) Software configuration: ``` section: links SERVER: right = CLIENT CLIENT: left = SERVER end ``` Monitor configuration: ``` Virtual Desktop: (0, -439) - (4000, 2121) Display Monitors: \\.\DISPLAY1 [primary] (0, 0) - (2560, 1440) [display] (0, 0) - (2560, 1400) [work area] \\.\DISPLAY2 (2560, -439) - (4000, 2121) [display] (2560, -439) - (4000, 2081) [work area] ``` **Client** Operating system: Windows 10 20H2 (latest) Software: Barrier 2.3.3 (latest) Monitor configuration: ``` Virtual Desktop: (0, -474) - (6256, 2086) Display Monitors: \\.\DISPLAY1 (2256, 72) - (4816, 1512) [display] (2256, 72) - (4816, 1472) [work area] \\.\DISPLAY2 [primary] (0, 0) - (1504, 1003) [display] (0, 0) - (1504, 963) [work area] \\.\DISPLAY3 (4816, -474) - (6256, 2086) [display] (4816, -474) - (6256, 2046) [work area] ``` **Issue** Almost certainly because the bounding box of the client monitors includes dead space (where no monitor area exists), the mouse can virtually move off the top and bottom edges of the primary monitor on the client and will take an equal amount of reverse movement to return (unless it has hit the bounding box). This is super annoying, especially as the client's mouse *visually* appears at the edge of the monitor even though Barrier's virtual position is way off the edge. The only way I've found to fix the sticky mouse is to enable `relativeMouseMoves` and turn on `lockCursorToScreen`. This is also what is required to make mouse control work in some games, so it's not entirely surprising it changes the behaviour here.

gitea-mirror commented

2026-05-05 06:25:52 -06:00

Author

Owner

@the-wes commented on GitHub (May 3, 2021):

That is a different issue from what was reported originally. Here are a bunch of open issues related to this:

https://github.com/debauchee/barrier/issues/1112
https://github.com/debauchee/barrier/issues/944
https://github.com/debauchee/barrier/issues/680
https://github.com/debauchee/barrier/issues/550
https://github.com/debauchee/barrier/issues/127

@the-wes commented on GitHub (May 3, 2021): That is a different issue from what was reported originally. Here are a bunch of open issues related to this: https://github.com/debauchee/barrier/issues/1112 https://github.com/debauchee/barrier/issues/944 https://github.com/debauchee/barrier/issues/680 https://github.com/debauchee/barrier/issues/550 https://github.com/debauchee/barrier/issues/127

gitea-mirror commented

2026-05-05 06:25:54 -06:00

Author

Owner

@twpol commented on GitHub (May 4, 2021):

This issue sounds a lot more like mine than any of those you've linked... as in, it matches https://github.com/debauchee/barrier/issues/573#issuecomment-593062014

I suppose making Barrier understand multi-monitor computers, as some of those other issues are, might indirectly help, but they don't seem to be describing the actual problem I am having - which is what this issue does

@twpol commented on GitHub (May 4, 2021): This issue sounds a lot more like mine than any of those you've linked... as in, it matches https://github.com/debauchee/barrier/issues/573#issuecomment-593062014 I suppose making Barrier understand multi-monitor computers, as some of those other issues are, might indirectly help, but they don't seem to be describing the actual problem I am having - which is what this issue does

gitea-mirror commented

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

Author

Owner

@sillyslux commented on GitHub (Oct 30, 2021):

The only way I've found to fix the sticky mouse is to enable relativeMouseMoves and turn on lockCursorToScreen.

I can confirm this works in a linux/linux setup as well. Below is what i have added to my configuration. This makes mouse movement fun again. Two downsides are, after cursor locking, mouse movement won't wake the monitors after they have switched to standby and obviously you have to unlock if you want to switch to the other computer at screen edge.
But ty @twpol ymmd.

section: options
	relativeMouseMoves = true
	keystroke(Control+Shift+F1) = lockCursorToScreen(toggle)
end

@sillyslux commented on GitHub (Oct 30, 2021): > The only way I've found to fix the sticky mouse is to enable `relativeMouseMoves` and turn on `lockCursorToScreen`. I can confirm this works in a linux/linux setup as well. Below is what i have added to my configuration. This makes mouse movement fun again. Two downsides are, after cursor locking, mouse movement won't wake the monitors after they have switched to standby and obviously you have to unlock if you want to switch to the other computer at screen edge. But ty @twpol ymmd. ``` section: options relativeMouseMoves = true keystroke(Control+Shift+F1) = lockCursorToScreen(toggle) end ```

No labels

Rows
Columns