mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 22:01:23 -06:00
[GH-ISSUE #575] client connects, but no sharing #451
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#451
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 @timeweaver on GitHub (Feb 27, 2020).
Original GitHub issue: https://github.com/debauchee/barrier/issues/575
Operating Systems
Server: RHEL 8
Client: Windows 10
Barrier Version
2.3.2
Steps to reproduce bug
My client connects, log on the client shows connected to server, log on server shows client connecting. But mouse won't travel between screens.
Other info
This is a first time setup - I disabled selinux and shut down firewalld on my redhat server in order to allow the client to connect. Not seeing errors in either log.
@timeweaver commented on GitHub (Feb 27, 2020):
Ok - I guess you can close this - It just magically started working - I have no idea why. I disabled ssl on both and nothing changed, so I re-enabled it. boom. working.
@timeweaver commented on GitHub (Feb 27, 2020):
And now it's not - not idea - help!!
@the-wes commented on GitHub (Mar 1, 2020):
Can you provide some log output? Turn it up to debug1 and see if you get any messages when trying to switch screens? Attach a screenshot of your server config?
@timeweaver commented on GitHub (Mar 3, 2020):
Ok, here's a log file with debug turned on. The txt file is the saved config. I don't see anything showing up when I move my mouse against the edge of the screen like it is even trying to switch. I've had two occasions where it started working for about 10 minutes or so, then just stopped. Sadly, I couldn't get it to work during this log capture.
barrier.log
barrier.txt
@nsclong commented on GitHub (Mar 6, 2020):
I have the same issue. I am running Debian 10 (server) and Windows 10 (client), both on Barrier version 2.2.0.
The machines are connecting to each other fine and talking to each other. Debug1 level log attached. However mouse just will not share. It stops at the edges of the server screen.
When I move my mouse to the edge of the screen to attempt to move to the client machine, nothing changes in the log.
barrier-server.log
If it's relevant, server screen size is 4K, whereas client is standard HD.
@timeweaver commented on GitHub (Mar 9, 2020):
Turns out my company won't let me use this software anyway. Thanks for your efforts, I'm gonna go cry in my milk now.
@ik3umt commented on GitHub (Mar 10, 2020):
Same issue here, server win10 + barrier 2.3.2 , client latest debian10 + barrier 2.2.0
Client connects to server, both ok on logs, logs tell entering and leaving screens at relative position, keyboard OK but no control over mouse
@nsclong commented on GitHub (Mar 12, 2020):
OK. I had this fixed briefly. I found that I had an old copy of 'Mouse Without Borders' on my Windows 10 machine. After uninstalling and rebooting, Barrier worked once...Debian server connecting to Windows client. But after rebooting both machines again, I can't get the darn thing to work again :(
@geertdobbels commented on GitHub (Apr 20, 2020):
Seems to be the same as #589 where I posted, but in the meantime I read this thread and also captured the log file with debug1.
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 (though I do not remember the barrier version number) 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:
Barrier server clearly sees the client, as can be seen in the logfile. After changing the log level to Debug1, I only once could see a couple of messages related to leaving the screen on the bottom (which I even do not remember having done), but after that no more messages to that effect appear, no matter how and on which border I try to leave the server screen.
Server has dual screen, but I tried with single screen: no change.
I also tried with and without SSL, no difference.
barrier.log
@geertdobbels commented on GitHub (Apr 20, 2020):
After starting barrier from the command shell, I saw a message related to a missing wayland-egl plugin, which made me think that wayland might be the problem (wayland is on by default in gnome 3.4 or at least in fedora31). This made me think that on my previous fedora31 install, I used to login under Xorg gnome, and not under wayland .....
So I logged out and logged back in but under xOrg gnome instead of the default wayland, and now barrier seems to be working. The question now is how to make barrier working under wayland....
@scottajohnson commented on GitHub (May 1, 2020):
I had the same problem with a Win7 Server and raspian clients. Scroll lock was turned on and that locked the mouse to the windows screens.
@deisi commented on GitHub (May 7, 2020):
I can confirm:
Server: 20.04 Ubuntu Xorg
Client: Arch linux Gnome 3.36.1 Wayland
Connection is handled correctly, and scrolling on client in open window on client works. However the mouse pointer on the client is not moved.
@gizmovt commented on GitHub (May 12, 2020):
I can confirm as well:
Server: 20.04 Ubuntu Desktop (Xorg)
Client: Fedora Workstation 32 (Xorg, installed via flatpak)
connects and enters screen but no mouse or keyboard
@marzukia commented on GitHub (May 13, 2020):
In the same boat, both machines Fedora32 running x11. Connects and logs reflect correct screen detection but both keyboard and mouse don't work
Edit: seems that during the process of updating my laptop to fedora 32 it reverted back to wayland. Works primo now thanks @simons-public
@simons-public commented on GitHub (May 13, 2020):
For any of the people using Wayland in this thread (i.e. RHEL 8 uses Wayland by default now) Wayland isn't supported by Barrier as of right now.
@CurtisDyer commented on GitHub (Sep 10, 2020):
So when I had this issue, it was actually user error. I had pressed scroll lock at some point, which locked the cursor to my server's screen. Just a heads-up for anyone else who's spacing out over the obvious (or maybe it's just me).
@p12tic commented on GitHub (Sep 22, 2020):
Closing as a duplicate of #247. The bug for actual Wayland support is in #109.
@frohro commented on GitHub (Sep 29, 2020):
This has been plaguing me for a good while. I have a touch screen, and found that touching the touch screen allowed me to get into the other screen. Here is the debug messages I was getting:
[2020-09-29T15:43:36] DEBUG1: try to leave "frohro-260" on right
[2020-09-29T15:43:36] DEBUG: locked by mouse buttonID: 0
@mic-lachmann commented on GitHub (Jan 15, 2021):
I have the same problem between win10 and OSX. When I assign switch to max screen to a hotkey, it works well, and then I can move my mouse back to win10, but from win10 I can't go to the max screnn
@ghost commented on GitHub (Feb 8, 2021):
ok it was working fine with me when it was mac the server for 1 win and 1 other mac both as clients , however i wanted to use the win as server other 2 macs clients, everything connects well but the mouse doesn't travel.
@rajeshdgsb commented on GitHub (Mar 30, 2021):
I had this same issue with barrier across a windos10 and Ubuntu20.04 .
Thanks to @CurtisDyer , I found that this was easy to fix by just undoing the scroll lock !
@Leathersoup commented on GitHub (Apr 9, 2021):
I experience this issue from time to time. I believe it is linked to running full screen apps on (in my case the barrier server). When the full screen application is shut down barrier does not seem to recover access to the screen edges.
@gogoprog commented on GitHub (Apr 23, 2021):
Experiencing the same issue from Linux to OSX.
It was working fine then I had a connection problem. When this problem was solved the client can connect but the cursor cannot enter to the client.
Scroll lock/unlock does not fix the issue.
@iraklis10 commented on GitHub (Jun 1, 2021):
The accepted answer to https://askubuntu.com/questions/961304/how-do-you-switch-from-wayland-back-to-xorg-in-ubuntu-17-10 solved the issue for me. Thanks to @geertdobbels for the pointer
@COUPON4Vitamins commented on GitHub (Jun 29, 2021):
I had the same issue. The culprit was "Scroll Lock." I didn't notice I had it on as the LED lights on my keyboard stopped working. Once I pressed on ScrLK, everything worked flawlessly again.
@frohro commented on GitHub (Jun 29, 2021):
I have discovered that this happens when something in the first screen is not completed before I try to go to the second screen. For example, if I open a menu, but don't select any item, but then try to go to the second screen, it will not allow me to do go there.
@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....
@msilmser commented on GitHub (Sep 20, 2021):
scroll lock was the answer for me
@henriquemod commented on GitHub (Nov 5, 2021):
Same here
@noob-max-ai commented on GitHub (Jan 10, 2022):
Any updates?
@AymenFJA commented on GitHub (Mar 23, 2022):
worked for me: I did not have a scroll lock in my physical keyboard but somehow it locked itself: https://support.microsoft.com/en-us/office/turn-off-scroll-lock-a78492cc-c124-4782-a38b-df46669520e0
@khaledbnmohamed commented on GitHub (Apr 19, 2022):
Maaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaan, That is supeeeer stupidddd that I lost multiple hours in it
@Lucatronlk commented on GitHub (May 18, 2022):
This fixed my issue!! Thanks!
I have one MacBook left - Windows - right .. and suddenly it stopped working. I could not leave the screen. I did not have SSL activated, so when I activated SSL the issue persisted. And a simple scroll unlock fixed it 💯
@vklepper commented on GitHub (Nov 9, 2022):
I had a similar problem after setting Windows display to 125%. Just in case this helps anyone.
Server: Win 11
Client: Ubuntu 22.04
@owolowo955 commented on GitHub (Nov 22, 2022):
I had the same problem, switching my Ubuntu 22.04 (client) from Wayland to Xorg Gnome.
This fixed my issue!! Thanks!
@deveciabdullah commented on GitHub (Apr 2, 2023):
vi /etc/gdm3/custom.conf
#WaylandEnable=false ###uncomment this line for disable wayland
systemctl restart gdm3
This fixed my issue
@DJArty commented on GitHub (Apr 18, 2023):
Working for me too, but dont think its normal to disable Wayland for all system just for barrier can work. Must work with wayland (not working now)
barrier from snap:
barrier 2.4.0-4-gac5a1bfd 682 latest/stable shymega
Server: Ubuntu 22.04 (Wayland by default)
Client: Windows 10
@architdbz commented on GitHub (May 4, 2023):
I had exactly same problem when I make Ubuntu as my server. When I make windows as my server the mouse is able to travel across the screen but becomes invisible. I found the solution to this problem in this link.
https://askubuntu.com/questions/1407275/mouse-disappears-while-using-barrier
All you have to do is edit custom.conf
$ sudo nano /etc/gdm3/custom.conf
uncomment this line if its already commented, and make it false
"WaylandEnable=false"
save and exit and then type
$ sudo systemctl restart gdm3
Barrier should now work properly. Hope this helps.
@stephenskett commented on GitHub (May 5, 2023):
Same here.
Weirdly, manually selecting the 'Ubuntu with xOrg' option at login screen didn't help in my case, but disabling Wayland in the GDM3 config did. 😖
Here's my setup, FWIW...
Server: Windows 11
Client: Ubuntu 22.04 LTS
@YuriyL-Git commented on GitHub (Jun 23, 2023):
For me helped to set Fix Scroll checkbox in settings
@Smartog commented on GitHub (Sep 6, 2023):
yes！yes！this way works for me. After pressing the SrcLk key on my keyboard, issue fixed!
@cieske commented on GitHub (Dec 13, 2023):
Can't sharing mouse suddenly happens, disabling scroll lock is the answer for me too:)
@AhmedKhan-GH commented on GitHub (Feb 22, 2024):
You are a legend
@Dakkaron commented on GitHub (Oct 7, 2024):
Late to the party, but switching over to Input Leap fixed the issue for me. They just released v3.0.0, which adds Wayland support.
(From what I gather, Barrier is discontinued and the devs forked it and renamed it Input Leap. Input Leap seems to be compatible to Barrier, so I'm currently running Barrier on one device and Input Leap on the other and it works. Don't know how long that will be the case, so update to Input Leap if you can.)
@frohro commented on GitHub (Oct 7, 2024):
Wow! Thanks for passing on the good news!