Linux Client: Cursor is always stuck in the bottom corner

[nini1294]

Operating Systems

Server: Windows 10 (Version 1803)

Client: Arch Linux (Manjaro KDE) (built from source)

Barrier Version

Server: 2.10
Client 2.10

Steps to reproduce bug

1. Connection is successful after adding exceptions to firewall
2. When the cursor goes enters the client it is stuck in the bottom right corner.
3. Keyboard is shared successfully and works when the cursor is in the client.

Other info

N/A

[CaptainJawZ]

I have the exact same problem
Server: Windows 10 dual monitor
Client: Windows 10

[dimhr12]

I have the same problem.
Server: Windows 8.1 Pro, version 6.3.9600
Client: Windows 10 Enterprise, version 10.0.17763

Running Barrier v2.1.0-RELEASE-0b2dfd80 in both machines.

I noticed also that the cursor enter Client distant from the border. Almost 80% of the screen of Server and the cursor jump to Client side, stucked in bottom right. If I move the mouse really FAST to the left, I can see the cursor and sometimes I get it back to Server side.

barrierSERVER.log
barrierCLIENT.log

[Pawn2e4]

If you use the latest version of Barrier from the AUR and set that as the server and use windows barrier 2.10 as the client instead, then it works perfectly.
The windows version of barrier seems to have this bug because it isn't as up to date as the linux version. Will probably be fixed on the next windows release.

Also, the bug seems to be caused by having a high resolution display. If you set your high resolution display to something lower (1920x1080) for example then it will probably work

[AdrianKoshka]

I haven't released a new windows build yet, mostly due to distraction.

[null-von-sushi]

I just tried out barrier and am also having this issue, do you know when the new windows build will be ready? Thanks!

[AdrianKoshka]

I haven't carved out the time yet, recently started a full-time job.

[s3v]

I had the same problem and changed the dpi scaling settings from 125% to 100% on the windows side to solve this. This might be why lowering the resolution as mentioned above also seems to work

Also, the bug seems to be caused by having a high resolution display. If you set your high resolution display to something lower (1920x1080) for example then it will probably work

Windows side: 2.1.0-RELEASE-0b2dfd80, display 2560x1440
Archlinux side: barrier 2.2.0, display 1920x1080

[oogba71]

I can confirm that changing the display scaling to 100% on the Windows server fixes this. It's less than ideal because it obviously makes screen elements tiny on a 1920x1080 14" laptop.

[sgieseking]

I compiled the latest code in the repository for Windows and it is working correctly in my configuration with a 3840x2160 display set to 175% scaling. The precompiled binary for Windows had the same problems that others have experienced.

Server: Windows 10 Pro (Version 1809), 3840 x 2160 display, 175% scaling
Client: Ubuntu 18.04, 3840 x 2160 display, DPI set to 169

[jehutywong]

+1
Server: 2.10
Client 2.10
Server: Windows 10 1803, 1920x1080, 125%scaling
Client: Fedora 29 Workstation, 3840 x 2160 display, scale 200%

[sommoMicc]

I compiled the latest code in the repository for Windows and it is working correctly in my configuration with a 3840x2160 display set to 175% scaling. The precompiled binary for Windows had the same problems that others have experienced.

Server: Windows 10 Pro (Version 1809), 3840 x 2160 display, 175% scaling
Client: Ubuntu 18.04, 3840 x 2160 display, DPI set to 169

How do I compile the code for windows from source?

[AdrianKoshka]

I don't know, fwiw, our windows binary is based off 2.1.0, where-as the linux one is based off 2.1.2.

[nyanpasu64]

I installed the Windows build at https://github.com/debauchee/barrier/releases/tag/v2.3.0 and get the same issue.

Windows server 125% scaling, Linux client 100% via Flathub.

[kundeng]

Server windows, Client MAC OS.

Same issue with the latest release.

Don't know how to fix. It worked once when I upgrade the windows binary, but now it's doing it again. Frustrating.

[Raniz85]

I've got the same issue.

Server: Windows 10 Pro 1903, Barrier 2.3.2-snapshot-210c2b70. 2 screens - 1 1080, 1 4K. Both using 100% text size
Client: Arch Linux, Barrier 2.3.2-RELEASE-0000000

[yume-chan]

See #94 and my comment

[jiboncom]

I can confirm that changing the display scaling to 100% on the Windows server fixes this. It's less than ideal because it obviously makes screen elements tiny on a 1920x1080 14" laptop.

Can confirm this works

[Alexey-Tsarev]

I confirm (set display scale to 100% and the issue disappears).

It looks like this helps:
#42 (comment)

[mflipe]

This happened to me right now.
MacOS and Windows 10
Setting the display scale to 100% solved the problem.

[jiboncom]

I fixed it using version 2.4 in the client (Mac) and 2.3.4 on the server (Windows)

[devxalted]

I can confirm that 100% scale is still applicable. Completely crazy behavior otherwise, and the mouse basically becomes useless on both client and server without this setting. This sucks though running at 4k resolution because everything becomes absolutely tiny.

Regardless, everything seems to be working pretty well otherwise and I am happy about that.

It is a little interesting that this issue was opened almost 3 years ago and it's still not resolved however.

[ravenium]

I just bumped from 2.3.4 to 2.4 and this happened (server win10 with 4k monitor, client MacOS with 2 1080p displays).

Changing to 100% scaling definitely fixes it, though I've had to then change the font scaling in my browser to 125% to compensate. Changing the compat settings didn't seem to help. Will try going back to 2.3.4 but I did want to try the client cert items.

[esuntp]

I can confirm 2.3.4 on the server and 2.4.0 on the clients works for me too. I never had this issue before 2.4.0. The server is Windows 11 and has two mac clients.

[anay-p]

I too can confirm that version 2.3.4 on Windows 10 Home 21H2 and scaling 125% as server and version 2.4.0 on Zorin OS 6 Core (based on Ubuntu 20.04. 3 LTS) as client works.

[fakuivan]

This happened to me right now. MacOS and Windows 10 Setting the display scale to 100% solved the problem.

Same, changing to 100% scaling on windows made it work

[rainerillichmann]

Same issue here with the 2.4.0 Windows server version, reducing the scale fixes the problem.

Also 2.3.4 Windows Server and 2.4.0 Windows client works fine.

[chbdetta]

See #94 and my comment

This solved the problem for me. Thanks!

[IngvarKofoed]

I can confirm that 2.3.4 Windows Server and 2.4.0 Windows client works fine. But if both are 2.4.0, it does not work (mouse stuck on client)

[ivan-georgiev]

With Windows server and client it started working only after:

• Downgraded server to 2.3.4 (client is 2.4.0)
• DPI was set to same value on both client and server (125% in my case)
• Not related to this, but I also hit this issue No ssl certificate on Windows 10 (v2.4) #1377 and had to generate the pem file on the server

[josephtesfaye]

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

[GSaiki26]

Hey, I was in the same situation. But I had noticed the mouse every time I tried to enter in the client display, It was going down a bit, so changing my display resolution and Refresh rate had fixed, so I returned the configs to the original and magically worked normal.

[violet4]

Also, the bug seems to be caused by having a high resolution display. If you set your high resolution display to something lower (1920x1080) for example then it will probably work

ahh.. also seems to happen when your Windows display scale and layout setting is >100% (i didn't check <100%)

[sebastianarca]

Hi ! Same issue for me.

Operating Systems

Server: Windows 11

Client: Debian 12

Barrier Version

Server: 2.4.0
Client 2.4.0

Steps to reproduce bug

• Connection is successful after adding exceptions to firewall
• When the cursor goes enters the client it is stuck in the bottom right corner.
• Keyboard is shared successfully and works when the cursor is in the client.

Other info

SSL Disable

[thaspius]

Still same issue

Windows 11 Server
Linux Mint 21.2 Victoria client

Both running Barrier 2.4.0

Connection works
drag cursor from windows to Mint and cursor is stuck in the bottom right corner

Changed windows to a lower resolution and 100% scaling and can use barrier as expected

[abdulmueez-dev]

Worked like charm! Changed dpi scalling from 125% to 100% on windows and its rocking on my ubnutu client!

[DaleBae]

I had the same problem and changed the dpi scaling settings from 125% to 100% on the windows side to solve this. This might be why lowering the resolution as mentioned above also seems to work

Also, the bug seems to be caused by having a high resolution display. If you set your high resolution display to something lower (1920x1080) for example then it will probably work

Windows side: 2.1.0-RELEASE-0b2dfd80, display 2560x1440 Archlinux side: barrier 2.2.0, display 1920x1080

It completely works for me. Thx!

[dasboogles]

Just ran into this myself. Why hasn't this been fixed? As resolutions get larger and larger, this is becoming more of an issue. I'm now sitting on a 1440p monitor @ 100% scaling and my eyes are SCREAMING.

Can we get a fix please? The above comments are not "fixed", they're "workarounds" waiting for a fix.

Thanks!

[Edit]: For anyone who wants a non-dpi answer there's a compatibility workaround for this issue: #1638