-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cursor is stuck in bottom of client screen. Issue with high resolution displays? #94
Comments
Reopen if your issue isn't resolved after 2.2. Thank you :) |
Sorry for opening the issue again, but I am experimenting the same problem, with similar devices, here is my setup: When I use my desktop as a client it works seamlessly, just as I expect it. |
Hello. |
So, as a test i've built the latest version of the code from the repo and the fix you have committed 075d4f4. Also i've noticed that the setup build script points to a folder wich doesn't exist. |
What do you mean? Could you get me log output from the build script? |
The line in the build_installer.bat tries to CD into build/setup wich isn't created by the build script. Log:
|
Also i've noticed that the error mentions to change the variable Q_BUILD_TYPE=Release, but in the clean_build.cmd the variable is called B_BUILD_TYPE=Release. |
did you read this? https://github.com/debauchee/barrier/wiki/Building-on-Windows Pretty sure you don't need to run |
I didn't so that's probably why 😄 . |
Turned on barrier again today, it broke again. Restarting barrier on both machines doesn't fix it. |
Oh, huh. |
In my experience sometimes barrier breaks the input system of either or both the server and the client. Restarting the machines themselves helps. |
Hello, This happens on my side too with the following setup:
I installed 2.3.1 on a brand new Mac Mini running Mojave. I can swear it worked once (I could see and move the client's cursor by moving server's mouse) then the client's cursor disappeared forever. Actually, it got stucked in the bottom right corner of the client's screen. Restarting Barrier on both server and client doesn't help. When both barriers and barrierc are started and connected, as soon as the server's cursor crosses the right screen edge (I use 2 screens on the server machine), it jumps to the client's bottom right of the screen and get stucked there. The only way I can get my mouse back on the server is by stopping barrierc on the client. Regards, |
Hello,
The problem only occurs if I have my second display connected. If I connect it, the cursor will change to the client and get stuck in the top right corner. My first display is an HiDPI one, so I doubt the HiDPI display itself is the root of the bug. |
There was a fix for client mode in #306, not sure why it's not applied for server mode and why it was removed in aea4881 as a "clean up". Anyway, I found a workaround which you can apply now (I only have one monitor, I'm not sure whether it will work with multiple monitors): EDIT: #94 (comment) contains updated instructions for more use cases.
Now it should work. |
Having this problem with a Surface Pro 5 as the server and Barrier 2.4 |
Confirmed this happened on Windows 10 20H2 (server) and MacOS 10.14.6 (client). The above High DPI workaround didn't help in my case. |
I am also facing this problem, using two Windows machines. Machine A:
Machine B:
Regardless of which machine acts as Server or Client, the behavior is exactly the same. Moving the mouse from the Server's screen onto the Client's immediately "traps" the Server's mouse on the bottom-right corner of the Client's screen. The only way I know to exit this state is to press "Reload" on the Client's Barrier GUI. I have tried resetting the Server's configuration, and reinstalling Barrier (version 2.4.0) on both machines. Let me know if there is anything I can do to help. I will happily install experimental versions and provide relevant logs. |
It seems 2.4 made this issue occur in a lot more environments than before. I'd seen issues like this before when changing DPI settings or attaching monitors while Barrier was running, but this only became a consistent issue for me after upgrading the server from 2.3.3 to 2.4.0. Downgrading the server from 2.4.0 back to 2.3.3 fixed the issue for me. I posted more details at #1423. I now see there are more similar reports about upgrading to 2.4 causing these issues (look at the newer comments in the older issues) at #206, #1363, #1364, #1382, #1405, #1415 and #1422. |
Thank you, @halter73 ; reverting to version 2.3.3 seems to have fixed the issue for me. |
I'm having the same issue. I also remember having it before 2.4.0 release, when I grabbed the latest version compiled from main like two months ago or more. |
Same issue of cursor getting stuck at the bottom right corner of the barrier client when attempting to switch control focus. The only way to regain control of my cursor on the server side seemed to be stopping the connection from the barrier client using a hardwired mouse/keyboard. Win10 (S) <-- Ubuntu 20.04 (C) both running Barrier v2.4.0. Reverting the server instance back to v2.3.4 seemed to fix the issue. |
Issue is definitely DPI related. If I change the scale to 100% it works fine with 2.4.0. The moment I switch it back to 125%, the cursor breaks again. :( |
Verified the above with Win10 server and both MacOS and Pop!_OS (latest versions) clients |
Same problem here. Problem disappers when I set the scaling to 100 percent. Reappears when the scaling is set to the default 150 %. Running Win 11 (server) MacOS 12 (client) barrier 2.4.0 |
For a Windows server, I changed the DPI settings on barriers.exe like @yume-chan's suggestion, but as it runs as system user, I chose "Change settings for all users". |
Thanks! "Change settings for all users" solved it for me as well :) |
Could you please share a screenshot of your settings? |
I did some research and forgot to post here. IIRC this issue is from here barrier/src/lib/platform/MSWindowsScreen.cpp Lines 1582 to 1588 in fc045fc
On the other hand, Barrier reads mouse position using Low Level Mouse Hooks which always return mouse coordinates in physical pixels. So when the cursor is at right/bottom border, barrier thinks it is out of bounds so it doesn't know what to do. About why does the workaround work, my guess is that it (incorrectly) makes For a proper code fix, Windows also has a |
Thanks a bunch. Confirmed working on my setup, no issues so far. Server: Win10, dual HDPI monitors, scaled |
Thank you! |
Changing the setting on the Windows (server) by applying to all users worked for me! |
Issue also occured for me. Server: Client; By changing the scaling of the 4k Screen from 150% to 100% i was able to get it running. |
Hi, I encounter this issue just today, my setup is: Barrier version: 2.4.0 Server (Windows 10):
Cliente (Windows 10):
Changing the compatibility configuration, as suggested, of barriers.exe in my server fixed it, thanks. |
Having the same mouse stuck in bottom right corner on client issue. Server = Windows 10 Changing the .exe DPI settings did not work for me. Changing Windows display settings from 150% scale to 100% fixed it. However, my server screen isn't useable for me at 100% scale
|
Can confirm having the scale at >100% causes problems. The hell! Can you help us 4K people out? |
Did you try @yume-chan / @hwti 's solution above? That works for most people. |
Operating Systems
Server: Windows 10 x64 1709
Client: macOS 10.13.5
Barrier Version
2.1.0
Steps to reproduce bug
I have a Surface book (3000x2000 scaled at 200%) with a 3840x2160 monitor above scaled at 150%.
My MacbookPro (1280x800) is to the right. Whenever I move the mouse to the mac, the cursor jumps straight to the bottom right screen and stays there. I can right click but not move it. I can use the mac trackpad to move the mouse but not the Windows mouse.
I disabled my laptop screen so I am only using the external display. Same issue.
I moved the orientation of the mbp to the right. Same issue.
The log shows the following warning when I move to the client screen: WARNING: cursor may not be visible
Other info
Logs are attached
clienttlog.txt
serverlog.txt
The text was updated successfully, but these errors were encountered: