mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #1382] Windows server makes cursor stuck on down-right corner in MacOS Monterey. #1074
Labels
No labels
HiDPI
bounty
bsd/freebsd
bsd/openbsd
bug
bug
build-infra
cantfix
critical
doc
duplicate
enhancement
fix-available
from git
from release
good first issue
help wanted
installer/package
invalid
linux
macOS
meta
needs testing
pull-request
query
question
regression
regression
v2.4.0
windows
wontfix
work-in-progress
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/barrier#1074
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
@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.
@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.
@filippo-orru commented on GitHub (Nov 22, 2021):
Same issue as https://github.com/debauchee/barrier/issues/1423
@kavanaram commented on GitHub (Nov 29, 2021):
Same problem on the same systems.
@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.
@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!
@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.
@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.
@josephtesfaye commented on GitHub (Jan 26, 2023):
Downloading the latest build from https://dev.azure.com/debauchee/Barrier/_build?definitionId=1 helped me.
@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.
@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
@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:
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
@AzumWatson commented on GitHub (Sep 10, 2024):
This worked, thanks for sharing the method