[GH-ISSUE #1382] Windows server makes cursor stuck on down-right corner in MacOS Monterey. #1074

Open
opened 2026-05-05 07:26:50 -06:00 by gitea-mirror · 13 comments
Owner

Originally created by @tranixx on GitHub (Nov 4, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1382

What happened?

Barrier server on Windows (2.4.0) causes cursor to be uncontrollable and stuck in a down-right corner in MacOS Monterey (12.0.1) using Barrier 2.4.0.

When I used older version of Barrier on Windows (2.3.2) and newest version of Barrier on MacOS (2.4.0), everything works flawlessly.

Log shows a warning that cursor may not be visible.

Version

From Git HEAD or commit (specify below)

Git commit hash (if applicable)

version 2.4.0

If applicable, where did you install Barrier from?

No response

What OSes are you seeing the problem on? (Check all that apply)

Windows, macOS

What OS versions are you using?

MacOS Monterey (12.0.1) using Barrier 2.4.0.
Windows 10 21H1 using Barrier 2.4.0.

Relevant log output

No response

Any other information

No response

Originally created by @tranixx on GitHub (Nov 4, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1382 ### What happened? Barrier server on Windows (2.4.0) causes cursor to be uncontrollable and stuck in a down-right corner in MacOS Monterey (12.0.1) using Barrier 2.4.0. When I used older version of Barrier on Windows (2.3.2) and newest version of Barrier on MacOS (2.4.0), everything works flawlessly. Log shows a warning that cursor may not be visible. ### Version From Git HEAD or commit (specify below) ### Git commit hash (if applicable) version 2.4.0 ### If applicable, where did you install Barrier from? _No response_ ### What OSes are you seeing the problem on? (Check all that apply) Windows, macOS ### What OS versions are you using? MacOS Monterey (12.0.1) using Barrier 2.4.0. Windows 10 21H1 using Barrier 2.4.0. ### Relevant log output _No response_ ### Any other information _No response_
gitea-mirror added the
bug
label 2026-05-05 07:26:50 -06:00
Author
Owner

@stephen-czetty commented on GitHub (Nov 4, 2021):

I am seeing this same behavior between a Windows 10 Server and a Windows 11 Client, both running 2.4.0.

Keyboard does work, though it's stuck on the client because I can't move the mouse back to the server.

If I downgrade the server to 2.3.4, leaving the client at 2.4.0, it behaves correctly again.

<!-- gh-comment-id:961160681 --> @stephen-czetty commented on GitHub (Nov 4, 2021): I am seeing this same behavior between a Windows 10 Server and a Windows 11 Client, both running 2.4.0. Keyboard does work, though it's stuck on the client because I can't move the mouse back to the server. If I downgrade the server to 2.3.4, leaving the client at 2.4.0, it behaves correctly again.
Author
Owner

@lostornot commented on GitHub (Nov 4, 2021):

Yes, same problem between Macos 12.0.1 and Win 11. and thanks @stephen-czetty, it works now.

<!-- gh-comment-id:961190154 --> @lostornot commented on GitHub (Nov 4, 2021): Yes, same problem between Macos 12.0.1 and Win 11. and thanks @stephen-czetty, it works now.
Author
Owner

@filippo-orru commented on GitHub (Nov 22, 2021):

Same issue as https://github.com/debauchee/barrier/issues/1423

<!-- gh-comment-id:975225027 --> @filippo-orru commented on GitHub (Nov 22, 2021): Same issue as https://github.com/debauchee/barrier/issues/1423
Author
Owner

@kavanaram commented on GitHub (Nov 29, 2021):

Same problem on the same systems.

<!-- gh-comment-id:982048176 --> @kavanaram commented on GitHub (Nov 29, 2021): Same problem on the same systems.
Author
Owner

@viternatofucrup commented on GitHub (Dec 12, 2021):

no connection at all in my case. m1 mac mini (Monterey) 2.4.0 installed and win11 2.4.0 installed. installing 2.3.4 on win11 fixed it.

<!-- gh-comment-id:991872914 --> @viternatofucrup commented on GitHub (Dec 12, 2021): no connection at all in my case. m1 mac mini (Monterey) 2.4.0 installed and win11 2.4.0 installed. installing 2.3.4 on win11 fixed it.
Author
Owner

@chuckrector commented on GitHub (Jan 15, 2022):

I had the same problem when upgrading from 2.3.3 to 2.4.0 on Monterey. My mouse cursor wasn't visible when it got stuck. Downgrading back to 2.3.3 fixed it. However, today I experienced the same issue with 2.3.3 briefly!

My arrangement:

LEFT = Windows 10 client @ 1920x1080
MIDDLE = Windows 10 server @ 3840x2160
RIGHT = macOS Monterey 12.1 @ 3072x1920 (16" MBP Retina)

I had been scaling my server desktop a lot recently for work-related reasons. Whenever I change desktop scales, both Barrier clients break and stop showing the mouse cursor. That's always been the case even before Monterey, so I've gotten into the habit of stopping Barrier on all clients while I muck around with the server desktop scale. That's worked for me fine in the past and I could always recover my clients by restarting them after I was done scaling the server desktop.

I finished my server desktop scaling shenanigans today (mostly in 1920x1080 at various scales) and then switched back to my "normal" settings: 3840x2160 at 150% scale. Then I started my clients. When I moused into the Monterey client, that is when I experienced the issue in this thread again -- no visible mouse cursor and clicking would click in the bottom right somewhere. I thought I was doomed but then I disabled both of my clients again and set my server back to 100% and enabled my clients again. The problem went away. It remained fixed even after I subsequently disabled my clients again and switched back to 150% scale and started my clients again.

Here's hoping this adds some useful data points toward debugging the issue!

<!-- gh-comment-id:1013560530 --> @chuckrector commented on GitHub (Jan 15, 2022): I had the same problem when upgrading from 2.3.3 to 2.4.0 on Monterey. My mouse cursor wasn't visible when it got stuck. Downgrading back to 2.3.3 fixed it. However, today I experienced the _same_ issue with 2.3.3 briefly! My arrangement: LEFT = Windows 10 client @ 1920x1080 MIDDLE = Windows 10 server @ 3840x2160 RIGHT = macOS Monterey 12.1 @ 3072x1920 (16" MBP Retina) I had been scaling my server desktop a lot recently for work-related reasons. Whenever I change desktop scales, both Barrier clients break and stop showing the mouse cursor. That's always been the case even before Monterey, so I've gotten into the habit of stopping Barrier on all clients while I muck around with the server desktop scale. That's worked for me fine in the past and I could always recover my clients by restarting them after I was done scaling the server desktop. I finished my server desktop scaling shenanigans today (mostly in 1920x1080 at various scales) and then switched back to my "normal" settings: 3840x2160 at 150% scale. Then I started my clients. When I moused into the Monterey client, that is when I experienced the issue in this thread again -- no visible mouse cursor and clicking would click in the bottom right somewhere. I thought I was doomed but then I disabled both of my clients again and set my server back to 100% and enabled my clients again. The problem went away. It remained fixed even after I subsequently disabled my clients again and switched back to 150% scale and started my clients again. Here's hoping this adds some useful data points toward debugging the issue!
Author
Owner

@chuckrector commented on GitHub (Jan 15, 2022):

To add even more color to this:

I upgraded all three machines to 2.4.0 again and it is working across all machines just fine now. However, it only works when my server is set to 100% scale. If I scale up at all, I experience the issue described in this thread.

<!-- gh-comment-id:1013562497 --> @chuckrector commented on GitHub (Jan 15, 2022): To add even more color to this: I upgraded all three machines to 2.4.0 again and it is working across all machines just fine now. However, it only works when my server is set to 100% scale. If I scale up at all, I experience the issue described in this thread.
Author
Owner

@tinyhare commented on GitHub (Apr 20, 2022):

I had the same problem.
Server Win10 with screen 125% scale, Client macOS Monterey , both version 2.4.0.
no problem when exchange the Server and Client side.

<!-- gh-comment-id:1103366485 --> @tinyhare commented on GitHub (Apr 20, 2022): I had the same problem. Server Win10 with screen 125% scale, Client macOS Monterey , both version 2.4.0. no problem when exchange the Server and Client side.
Author
Owner

@josephtesfaye commented on GitHub (Jan 26, 2023):

Downloading the latest build from https://dev.azure.com/debauchee/Barrier/_build?definitionId=1 helped me.

<!-- gh-comment-id:1404587301 --> @josephtesfaye commented on GitHub (Jan 26, 2023): Downloading the latest build from https://dev.azure.com/debauchee/Barrier/_build?definitionId=1 helped me.
Author
Owner

@mvoelske commented on GitHub (Mar 4, 2023):

Can confirm @tinyhare's observation: setting the display scale on the server to anything other than 100% gets me the cursor-stuck-in-corner issue as well. Client and server both win11 running 2.4.0 here.

<!-- gh-comment-id:1454749768 --> @mvoelske commented on GitHub (Mar 4, 2023): Can confirm @tinyhare's observation: setting the display scale on the server to anything other than 100% gets me the cursor-stuck-in-corner issue as well. Client and server both win11 running 2.4.0 here.
Author
Owner

@dogasantos commented on GitHub (Mar 10, 2023):

same thing here
I'm using 2 27'' monitors on a windows (server) and a macbook 13 as client.
Windows sets 150% scale as recommended, but Barrier only works (as described here) when set scale back to 100% on windows.

Update;
there is a PR for this :

https://github.com/debauchee/barrier/pull/1543

<!-- gh-comment-id:1464364299 --> @dogasantos commented on GitHub (Mar 10, 2023): same thing here I'm using 2 27'' monitors on a windows (server) and a macbook 13 as client. Windows sets 150% scale as recommended, but Barrier only works (as described here) when set scale back to 100% on windows. Update; there is a PR for this : https://github.com/debauchee/barrier/pull/1543
Author
Owner

@arxidaki commented on GitHub (Aug 22, 2024):

Same issue here when using scaling on the windows side. The fix:

Go to the Barrier installation folder, typically "C:\Program Files\Barrier"
Go to each executable file and do this:

  • Right click, Properties
  • Compatibility tab
  • Change settings for all users
  • Change high DPI settings
  • Tick 'Override high DPI..." and select Application from the dropdown menu
  • Ok, Ok, Ok
  • Do the same on the next executable file

Currently I have in there: barrier.exe, barrierc.exe, barrierd.exe, barriers.exe, guiunittests.exe, integtests.exe, openssl.exe
I'm not sure if I needed to do it on every file, but couldn't be bothered to try and verify each file individually
What we achieved like that is to make Barrier ignore the system's scaling setting, that obviously messes up its internal positioning math, and trick it into acting like there is no scaling going on

<!-- gh-comment-id:2304400939 --> @arxidaki commented on GitHub (Aug 22, 2024): Same issue here when using scaling on the windows side. The fix: Go to the Barrier installation folder, typically "C:\Program Files\Barrier" Go to each executable file and do this: - Right click, Properties - Compatibility tab - Change settings for all users - Change high DPI settings - Tick 'Override high DPI..." and select Application from the dropdown menu - Ok, Ok, Ok - Do the same on the next executable file Currently I have in there: barrier.exe, barrierc.exe, barrierd.exe, barriers.exe, guiunittests.exe, integtests.exe, openssl.exe I'm not sure if I needed to do it on every file, but couldn't be bothered to try and verify each file individually What we achieved like that is to make Barrier ignore the system's scaling setting, that obviously messes up its internal positioning math, and trick it into acting like there is no scaling going on
Author
Owner

@AzumWatson commented on GitHub (Sep 10, 2024):

Same issue here when using scaling on the windows side. The fix:

Go to the Barrier installation folder, typically "C:\Program Files\Barrier" Go to each executable file and do this:

  • Right click, Properties
  • Compatibility tab
  • Change settings for all users
  • Change high DPI settings
  • Tick 'Override high DPI..." and select Application from the dropdown menu
  • Ok, Ok, Ok
  • Do the same on the next executable file

Currently I have in there: barrier.exe, barrierc.exe, barrierd.exe, barriers.exe, guiunittests.exe, integtests.exe, openssl.exe I'm not sure if I needed to do it on every file, but couldn't be bothered to try and verify each file individually What we achieved like that is to make Barrier ignore the system's scaling setting, that obviously messes up its internal positioning math, and trick it into acting like there is no scaling going on

This worked, thanks for sharing the method

<!-- gh-comment-id:2339494222 --> @AzumWatson commented on GitHub (Sep 10, 2024): > Same issue here when using scaling on the windows side. The fix: > > Go to the Barrier installation folder, typically "C:\Program Files\Barrier" Go to each executable file and do this: > > * Right click, Properties > * Compatibility tab > * Change settings for all users > * Change high DPI settings > * Tick 'Override high DPI..." and select Application from the dropdown menu > * Ok, Ok, Ok > * Do the same on the next executable file > > Currently I have in there: barrier.exe, barrierc.exe, barrierd.exe, barriers.exe, guiunittests.exe, integtests.exe, openssl.exe I'm not sure if I needed to do it on every file, but couldn't be bothered to try and verify each file individually What we achieved like that is to make Barrier ignore the system's scaling setting, that obviously messes up its internal positioning math, and trick it into acting like there is no scaling going on This worked, thanks for sharing the method
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/barrier#1074
No description provided.