Linux Client: Cursor is always stuck in the bottom corner

[ghost]

This issue has been migrated from old Barrier Github repository debauchee/barrier#206

Issue created on: 2018-12-22 by @nini1294
Issue last updated on: 2021-11-07

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

---

Commented on: 2019-01-06 by @CaptainJawZ

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

---

Commented on: 2019-01-16 by @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

---

Commented on: 2019-01-26 by @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

---

Commented on: 2019-01-27 by @AdrianKoshka

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

---

Commented on: 2019-01-30 by @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!

---

Commented on: 2019-01-31 by @AdrianKoshka

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

---

Commented on: 2019-02-12 by @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

---

Commented on: 2019-02-15 by @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.

---

Commented on: 2019-02-19 by @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

---

Commented on: 2019-03-18 by @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%

---

Commented on: 2019-04-09 by @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?

---

Commented on: 2019-04-09 by @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.

---

Commented on: 2019-07-22 by @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.

---

Commented on: 2019-09-11 by @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.

---

Commented on: 2019-11-07 by @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

---

Commented on: 2021-10-05 by @yume-chan

See #94 and my comment

---

Commented on: 2021-11-02 by @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

---

Commented on: 2021-11-03 by @Alexey-Tsarev

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

It looks like this helps:
debauchee/barrier#42 (comment)

---

Commented on: 2021-11-07 by @mflipe

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

---

Commented on: 2021-11-07 by @jiboncom

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