mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #589] connected but not able to move mouse over #460
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#460
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 @kundeng on GitHub (Mar 13, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/589
mac as server, windows 10 as client works fine.
windows 10 as server and mac as client connects but mouse doens't move over.
I tried everything:
on windows server, adjust HIDPI.
on windows server, disable sharing
Still nothing works so far. Anyone else have this problem???
@kundeng commented on GitHub (Mar 13, 2020):
I also turned on the debug.
It says "no neighbor up"
But on both client and server side, it also says connected.
@kundeng commented on GitHub (Mar 13, 2020):
Worked by https://github.com/debauchee/barrier/issues/42
scroll to middle about which exec to change properties of.
@geertdobbels commented on GitHub (Apr 20, 2020):
I have a similar problem on a different configuration:
Server : Linux Fedora 31 (installed via flatpak)
Client: Windows 10
Barrier Version 2.3.2 on both computers.
I had barrier working on the same configuration for several months without problems but then due to a technical problem, I had to reinstall Fedora31, and since then I have the following issue:
Each time I start or reload Barrier, I can clearly see the cursor arrow on the windows client dissapear, so there clearly is a connection, but then there is no way to get the cursor moving from my Fedora Server to my Windows client. The cursor stays on the border of my server screen.
I tried left, right, etc.... in case I got the configuration of client on the left or right wrong. I also tried with and without SSL both on server as on client, but it does not change the behaviour. I checked the firewall and all necessary ports seem to be open.
Any idea what could be happening here ?
@github-actions[bot] commented on GitHub (Sep 27, 2020):
This issue has been automatically marked as stale due to inactivity. It will be closed if no further activity occurs. Thank you for your contributions.
@nautix commented on GitHub (Dec 8, 2020):
This just started with me, too.
For months, I used a Debian Buster server and a Windows 10 client with Barrier 2.3.2 on both. Then the Debian Buster server went away, so I booted up a little-used machine running Peppermint Bionic. I reconfigured the Windows machine as the server and the Peppermint machine as the client. It worked great for a few days.
This morning, I ran a long-overdue 'apt-get upgrade' on the Peppermint box. After rebooting, Barrier still seemed to work fine, though I did not do a thorough test. But, this afternoon, Barrier logs show a connection but the mouse pointer isn't moving to the client.
I poked around a bit, turning off various options and reloading client and server, all to no avail. Then I noticed that the Peppermint box had a newer version of Barrier running: 2.3.3. I uninstalled Barrier 2.3.2 on the Windows server, then downloaded and installed Barrier 2.3.3. But no joy.
Reloading both client and server: still no mouse pointer on the client (except using the native touchpad).
Stopping and restarting both: no joy.
Quitting and restarting both: no joy.
Rebooting both: no joy.
The logs always show a successful connection at both ends, but the mouse pointer never moves on the client. (Yes, I made sure the server config had the client positioned in the correct location.)
sigh
Any (new) ideas?
@mneilly commented on GitHub (Jan 4, 2021):
I'm seeing similar issues between two Debian Buster boxes. It started about a month (?) ago with 2.3.2 built from source.
I just updated to 2.3.3 from the backports repo on both machines. They connect but I can't move the mouse cursor on the client. Oddly, chrome (and slack) partially work. I can use tab to change focus in chrome and even though there is no cursor movement the selection is visible, I can click on links and I can enter a new URL. Switching to a terminal window on the client with the real keyboard then trying to type with barrier doesn't produce any input...
System shortcuts have no effect. If I use Alt-Tab or press the super/windows key nothing happens.
FWIW - The debug output from pressing the super key is as follows:
@mneilly commented on GitHub (Jan 4, 2021):
FWIW - I just switched the client from GNOME to GNOME on Xorg and it started working again. Sorry, this is probably a different issue than the original report.
@andreluiztorres commented on GitHub (Sep 3, 2021):
I've found it works fine when we're running a full-screen program. Minimized doesn't really allow you to hover from one screen to another....
@zerlgi commented on GitHub (Sep 14, 2021):
YIp. I had assumed I was still on Xorg. After a reboot my Ubuntu session had switched itself to Wayland.
Logged out, set session to Ubuntu on Xorg. Barrier working beautifully.
I have now edited
/etc/gdm3/custom.confto force it to use XorgServer is Ubuntu 20.04 Xorg. Barrier: 2.3.2+dfsg-1build1
Client is Ubuntu 21.10 pre-release (now back on) Xorg. Barrier: 2.3.3+dfsg-1.1
Both running barrier installed via standard Ubuntu apt repository
@AngeloCello commented on GitHub (May 29, 2022):
Go to on the command line
$ sudo nano /etc/gdm3/custom.conf
UNCOMMENT THIS
#WaylandEnable=false
Press CTRL + X to save
EXIT by pressing enter
Restart computer
$ sudo systemctl restart gdm3
Im using Windows 10 as the Server and Ubuntu as Client
Keep in mind im using version Barrier 2.3.4 on Windows
This one worked for me
@TepidP commented on GitHub (Jun 2, 2022):
Also worked for me, thanks
But mine wasn't custom.config but daemon.config
@Suheb786 commented on GitHub (Jun 22, 2022):
Go to on the command line $ sudo nano /etc/gdm3/custom.conf
UNCOMMENT THIS #WaylandEnable=false
it works well the only drawback is the built in gestures was not working on my ubuntu 22LTS
@rafaelgalle commented on GitHub (Aug 8, 2022):
Also worked for me, thanks
@juanbomfim22 commented on GitHub (Aug 18, 2022):
SOLUTION: Press Scroll Lock
I accidentally pressed the ScrLk key and it disallowed me to move the mouse from one screen to another. I pushed again and it worked again.
@theLucasAntunes commented on GitHub (Dec 16, 2022):
It just started happening to me... My server is on Windows, the client still works normally. Even if I switch to using the client as the server it works properly. The only way to fix it is restarting Windows, which is rarely a pleasurable thing to do since I mainly use it and have to reopen everything later.
It seems my hotkey for toggling the mouse on-screen lock is getting stuck somehow. I'm not sure, but that's what it seems because at some point it just stops working forever (my keyboard doesn't have the Scroll Lock key so that wouldn't be the cause unless something else triggered it and now I can't turn it off).
The only logs I get, repeatedly, are:
Edit: I have two monitors and a TV connected to my main PC, as such:
TV
Monitor 2
Monitor 1
My client is to the left of Monitor 1, and when I disabled the TV screen it worked as expected. I believe this is somewhat related to #763, at least in my case.
@BlackFrameAI commented on GitHub (Jan 17, 2023):
YOU are a bloody life saver! Did the same thing after getting stuck on a full screen app and trying to discover how to exit it so pressed every key on keyboard, lol didn't occur to me even once that a keybind would disable barrier from working like that even after rebooting and restarting lol
@prithuls commented on GitHub (Feb 12, 2023):
After doing all of the steps, my client (ubuntu) was not accepting mouse. There was an invisible cursor. Anyway, I noticed my server (windows) barrier version was 2.4.0 and downgraded to 2.3.4. It worked!
@gerry1944 commented on GitHub (Mar 4, 2023):
Thank you prithuls.
Downgrading to 2.3.4 also solved the problem for me.
Many thanks
Gerry
@r14n commented on GitHub (Mar 23, 2023):
Disabling Wayland also worked for me to get barrier running 👍
@renaner123 commented on GitHub (Jun 28, 2023):
Also worked for me, thanks
Server: Windows 10 (19045.3086)
Client: Ubuntu 22.04 LTS
Barrier: 2.4.0
@JuninhoFreitas commented on GitHub (Mar 13, 2024):
Yeah!!!, working.
Server: Windows 10
Client: Ubuntu 22.04
@lsc4719 commented on GitHub (May 24, 2024):
Downgrade from 2.4 to 2.3.4 also work for me.
Great!!!!!!!!
@meestahp commented on GitHub (Aug 7, 2024):
Just wanted to add this in case someone else might come across this one, I was having the same error, which was caused by xrandr having another monitor which wasn't connected at the time, fixed with
xrandr --output HDMI-1 --offobviously change HDMI-1 to your monitor's name. server: fedora Jam 39, input-leap 2.4.0, clients: fedora kde, input-leap 2.4.0, windows 10, Barrier 2.4.0@AJCGxD commented on GitHub (Oct 12, 2024):
This method worked for me on the day I found this fix, but all of a sudden it has stopped working the next day. I dint change any settings or anything today, but it has stopped working. It just connects to the other monitor but when I move the mouse to the edge of the windows 11 screen it doesn't move over to the Ubuntu screen.
Windows 11
Barrier version: 2.3.4
Ubuntu 24.02.1
Barrier version: 2.4
@eddelbuettel commented on GitHub (Dec 13, 2024):
FWIW same issue between Ubuntu 24.04 (barrier server) and Ubuntu 24.10 (barrier client) -- forced the latter to use x.org, and the cursor becomes visible / responsive.
@codeIshan commented on GitHub (Oct 16, 2025):
It worked for me!!
server: ubuntu 22.04
client: windows 11
@nbolton commented on GitHub (Oct 16, 2025):
Try Deskflow or Input Leap, as Barrier is no longer in development.
https://github.com/deskflow/deskflow
https://github.com/input-leap/input-leap
If this is still an issue in those projects, we would appreciate a cross-post of this issue.