Cursor is stuck in bottom of client screen. Issue with high resolution displays?

mcx808 commented 6 years ago

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

When did the problem start to occur? Every time the above steps are followed
Is there a way to work around it? No
Does this bug prevent you from using Barrier entirely? Yes

Logs are attached clienttlog.txt serverlog.txt

walker0643 commented 5 years ago

@mcx808 this should be fixed with 075d4f4758f86c49ef0b5257a2de076b1d7d4569. can you try it and report back? if you're not comfortable building barrier from source this fix will be included in the next release (2.2). thanks!

walker0643 commented 5 years ago

Reopen if your issue isn't resolved after 2.2. Thank you :)

CaptainJawZ commented 5 years ago

Sorry for opening the issue again, but I am experimenting the same problem, with similar devices, here is my setup: [Desktop] [Desktop} [Surface pro]

When I use my desktop as a client it works seamlessly, just as I expect it. However, when I try to run the surface as a client, the mouse just get's stuck on the bottom of the screen, top left corner. I don't know if it's a DPI issue, or if it's a problem with multiple monitor setup, which I still havent figured out what's the right way to set, is it making two monitors with the same name?

luckcolors commented 5 years ago

Hello. I'm having the same issue. I'm willing to help you debug this, feel free to ask me things to test.

luckcolors commented 5 years ago

So, as a test i've built the latest version of the code from the repo and the fix you have committed https://github.com/debauchee/barrier/commit/075d4f4758f86c49ef0b5257a2de076b1d7d4569. And it's working correctly so yeah this issue should be already fixed. Please make an ufficial build whenever you get the chance. 😄 Thanks for your help.

Also i've noticed that the setup build script points to a folder wich doesn't exist.

AdrianKoshka commented 5 years ago

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?

luckcolors commented 5 years ago

The line in the build_installer.bat tries to CD into build/setup wich isn't created by the build script. Instead two folders wich are named similarly are present: setup-wix, setup-inno. I guess it's just a broken reference?

Log:

C:\barrier>build_installer.bat
Cannot find the specified file.
To build a 64-bit Windows installer:
 - set Q_BUILD_TYPE=Release in build_env.bat
 - also set other environmental overrides necessary for your build environment
 - run clean_build.bat to build Barrier and verify that it succeeds
 - re-run this script to create the installation package

luckcolors commented 5 years ago

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. Setting Q_BUILD_TYPE=Release does nothing. (Also i did build successfully barrier by setting the proper variables before so no idea about this).

AdrianKoshka commented 5 years ago

did you read this? https://github.com/debauchee/barrier/wiki/Building-on-Windows Pretty sure you don't need to run build_installer.bat.

luckcolors commented 5 years ago

I didn't so that's probably why 😄 .

luckcolors commented 5 years ago

Turned on barrier again today, it broke again. Restarting barrier on both machines doesn't fix it.

AdrianKoshka commented 5 years ago

Oh, huh.

p12tic commented 5 years ago

In my experience sometimes barrier breaks the input system of either or both the server and the client. Restarting the machines themselves helps.

FredNass commented 4 years ago

Hello,

This happens on my side too with the following setup:

Server : Linux Fedora 31 with barrier 2.3.2-snapshot-9080ce45 installed with Snap
Client : macOS Catalina 10.15.2 with barrier 2.3.2 downloaded from Github

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. Restarting both machines does not help either. Uninstalling and reinstalling did not help Upgrading macOS to Catalina did not 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, Frédéric.

emilpaw commented 4 years ago

Hello, I have the same problem.

Server : Windows 10 in a Dual Display Setup with barrier 2.3.2
Client : Arch Linux with barrier 2.3.2

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. When I don't use my second display, everything runs fine.

My first display is an HiDPI one, so I doubt the HiDPI display itself is the root of the bug.

yume-chan commented 2 years ago

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 aea488167af19845369e062bf9af4edfadc4fa71 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: https://github.com/debauchee/barrier/issues/94#issuecomment-979408763 contains updated instructions for more use cases.

Open Explorer and navigate to Barrier installation folder
Right-click on barrierc.exe or barriers.exe depends on your usage (client mode vs server mode), or both if you use both
Select "Properties"
Switch to "Compatibility" tab and click the "Change high DPI settings" button
In the new dialog, check "Override high DPI scaling behavior" and make sure "Application" is selected in the "Scaling performed by" dropdown menu
Click "OK" twice to close both dialogs
Kill all barrier*.exe processes or simple restart the computer

Now it should work.

jiboncom commented 2 years ago

Having this problem with a Surface Pro 5 as the server and Barrier 2.4

paulrrogers commented 2 years ago

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.

Gooseheaded commented 2 years ago

I am also facing this problem, using two Windows machines.

Machine A:

Operating System: Windows 10 Home 64-bit (10.0, Build 19042) (19041.vb_release.191206-1406)
Barrier: 2.4.0-release-3e0d758b
User DPI Setting: 120 DPI (125 percent)
System DPI Setting: 120 DPI (125 percent)

Machine B:

Operating System: Windows 10 Pro 64-bit (10.0, Build 19043) (19041.vb_release.191206-1406)
Barrier: 2.4.0-release-3e0d758b
User DPI Setting: 240 DPI (250 percent)
System DPI Setting: 288 DPI (300 percent)

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. I have also tried @yume-chan 's proposed workaround, but it did not help me. I am also able to reproduce this issue among machines that do not have high-resolution displays. (I have a third Windows machine running into this same problem, not included here for simplicity).

Let me know if there is anything I can do to help. I will happily install experimental versions and provide relevant logs.

halter73 commented 2 years ago

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 https://github.com/debauchee/barrier/issues/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 https://github.com/debauchee/barrier/issues/206, https://github.com/debauchee/barrier/issues/1363, https://github.com/debauchee/barrier/issues/1364, https://github.com/debauchee/barrier/issues/1382, https://github.com/debauchee/barrier/issues/1405, https://github.com/debauchee/barrier/issues/1415 and https://github.com/debauchee/barrier/issues/1422.

Gooseheaded commented 2 years ago

Thank you, @halter73 ; reverting to version 2.3.3 seems to have fixed the issue for me.

FliesWithWind commented 2 years ago

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.

jhspyhard commented 2 years ago

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.

FliesWithWind commented 2 years ago

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. :(

evertiro commented 2 years ago

Verified the above with Win10 server and both MacOS and Pop!_OS (latest versions) clients

XanderDK commented 2 years ago

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

hwti commented 2 years ago

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". The issue is then fixed after restarting the Barrier server.

FliesWithWind commented 2 years ago

Thanks! "Change settings for all users" solved it for me as well :)

XanderDK commented 2 years ago

Could you please share a screenshot of your settings?

FliesWithWind commented 2 years ago

yume-chan commented 2 years ago

I did some research and forgot to post here. IIRC this issue is from here

https://github.com/debauchee/barrier/blob/fc045fc79326cef966405b1cc578e8f062ae5294/src/lib/platform/MSWindowsScreen.cpp#L1582-L1588

GetSystemMetrics is not DPI aware and returns screen size as scaled to 100% DPI (much smaller than your real screen size).

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.

Untitled-1

About why does the workaround work, my guess is that it (incorrectly) makes GetSystemMetrics to return non-scaled values.

For a proper code fix, Windows also has a GetSystemMetricsForDpi API. However, I don't know which DPI should be used here (especially for multi-monitor setup with different DPIs).

JasonRayne commented 2 years ago

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". The issue is then fixed after restarting the Barrier server.

Thanks a bunch. Confirmed working on my setup, no issues so far.

Server: Win10, dual HDPI monitors, scaled Client 1: MacOS Monterey, single monitor, non-HDPI Client 2: Kali 2022.1, single monitor, non-HDPI

daejungkim commented 2 years ago

Thank you!

jpvanoosten commented 1 year ago

Changing the setting on the Windows (server) by applying to all users worked for me!

UjmaIT commented 1 year ago

Issue also occured for me. Here My setup:

Server: Windows 10 with 2x FullHD screens (100% sacling) and 1x 4k screen with 150% scaling.

Client; Windows 11 with a FullHD Screen

By changing the scaling of the 4k Screen from 150% to 100% i was able to get it running.

Rayanfpv commented 1 year ago

I managed to fix my Windows 10 with dual monitors (as a server), and Steam Deck (desktop mode as a client) by making sure both environment displays are on the same scale, in my case 100%.

windows 1 Windows 2

https://user-images.githubusercontent.com/43546382/221292147-15514d1c-f252-49bd-a5b0-e18e787b4843.mp4

d-marquina commented 1 year ago

Hi, I encounter this issue just today, my setup is:

Barrier version: 2.4.0

Server (Windows 10):

Screen 1: 1920*1080 at 150% scaling
Screen 2: 1920*1080 at 125% scaling

Cliente (Windows 10):

Screen: 1920*1080 at 125% scaling

Changing the compatibility configuration, as suggested, of barriers.exe in my server fixed it, thanks.

jartuso commented 1 year ago

Having the same mouse stuck in bottom right corner on client issue. Using Barrier 2.4.0 -- previously this same setup was working on 2.3.4

Server = Windows 10 Client = Steam Deck

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

I did some research and forgot to post here. IIRC this issue is from here

https://github.com/debauchee/barrier/blob/fc045fc79326cef966405b1cc578e8f062ae5294/src/lib/platform/MSWindowsScreen.cpp#L1582-L1588

GetSystemMetrics is not DPI aware and returns screen size as scaled to 100% DPI (much smaller than your real screen size).

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 GetSystemMetrics to return non-scaled values.

For a proper code fix, Windows also has a GetSystemMetricsForDpi API. However, I don't know which DPI should be used here (especially for multi-monitor setup with different DPIs).

foxotic commented 6 months ago

Can confirm having the scale at >100% causes problems. The hell! Can you help us 4K people out?

livejamie commented 3 months ago

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.

debauchee / barrier