mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #1166] Keyboard not switching correctly #934
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#934
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 @sbmaggarwal on GitHub (May 21, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1166
Describe the bug
I have connected 3 Apple machines (1 Mac Mini, 2 Macbook Pro) with Barrier with Apple Keyboard/Mouse. When I started my machines this morning, it started normally but after 15-20 minutes, the keyboard stopped sending keystrokes to client machines. Surprisingly, the sound increase/decrease/mute key on the keyboard works fine across the server and clients but characters and number keystrokes don't work.
Expected behaviour
The keyboard should work seamlessly across server-client machines.
Screenshots
N/A
Desktop (please complete the following information):
@mrpj100 commented on GitHub (May 21, 2021):
I've started getting this issue today (twice so far) and am similarly using a Mac (Big Sur 11.2.3, with Barrier server 2.3.3-release-3395cca9) and my Windows machine (Win10, running the same version of Barrier as a client). A Mac reboot fixed the problem initially but it recurred later in the day aftera few hours.
What I observe is that keystrokes stop transferring from the server machine to the client, even though mouse actions still transfer fine. Moving the mouse to the client screen and typing results in the keystrokes continuing to be sent to the server. I'm wondering if some update to the OS on the Mac is part of the problem.
@athornton commented on GitHub (May 21, 2021):
I'm seeing this too. Big Sur 11.3 (m1) on server, 11.3.1 (amd64) client. Rebooting the machine running the server was required, and keystrokes are moving again after the reboot, but I don't expect that to last.
@shaunchurch commented on GitHub (May 21, 2021):
I've started seeing this issue today as well, after working without a problem for months. Only thing that seems to fix it is a reboot of the mac server machine. Restarting the app or locking and unlocking the machine doesn't seem to do it.
Server: macOS Catalina 10.15.6, 2.3.3-release-3395cca9
Client: Windows 10, 2.3.3-release-3395cca9
@chaos95 commented on GitHub (May 24, 2021):
I'm also seeing this issue, identical behaviour to those above.
Server: macOS Big Sur 11.3.1 (MacBook Air M1), 2.3.3-release-3395cca9
Client: Windows 10, 2.3.3-release-3395cca9
@chaos95 commented on GitHub (May 24, 2021):
Update - I also discovered a handful of new crash reports from
barrierswhich I've never experienced before. All created since I started having the keyboard issue. I've attached one here; hopefully it can be of some use!barriers_2021-05-24-132503_ascension.crash.log
@athornton commented on GitHub (May 24, 2021):
A very slightly less disruptive workaround than a reboot (I too found lock/unlock cycle didn't help): log out and back in on the server.
@mickdarling commented on GitHub (Jun 24, 2021):
Workaround - Put your barrier server Mac to sleep for a few seconds and key commands should start working again on the client machines once you wake the Server Mac up.
@p12tic commented on GitHub (Jun 25, 2021):
Thanks for the bug report!
@Shawnfreebern commented on GitHub (Jul 9, 2021):
I'm also seeing this problem every morning when waking up server/client from sleep. Catalina server, big sur client. I'm actually running
/Applications/.../barriers -D DEBUG -ffrom the command line on a regular basis but I don't see any errors in the log, and killing (ctrl-c) and restarting both client & server doesn't fix the issue - I've needed to reboot the server machine to get keystrokes sending again. I'll try logout/login next time.@franciscodavid commented on GitHub (Jul 13, 2021):
This seems related to Secure Input. Every time I have this problem, some process has it enabled.
This comment was useful for me.
@vknightbd commented on GitHub (Jul 15, 2021):
omg. You solved the issue for me! I followed your post which describes MacOS Secure Input.
ioreg -l -w 0 | grep SecureInputto find the process (which in my case was PID=676), thenps auxww | grep "\<676\>"to find the process name, which was Chrome browser, and it turned out that my web email session expired and kicked me back to the login page with the cursor at the password input. I closed the tab and it fixed it! /facepalmThis seems like a common enough problem that that original comment mentioned ShareMouse had a "Secure input warning" feature. Maybe barrier should have that feature too, enabled by default for MacOS, (so after we switch to client screens, it checks for SecureInput and gives a notification.)
@cristianmenghi commented on GitHub (Aug 20, 2021):
Hi, same problem here in catalina 10.15.7, barrier server 2.3.3 client ubuntu 20.04
Following search of SecureInput, found /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console
I lost the keyboard in the client after the mac lock screen with the screenserver.
@sadokx commented on GitHub (Sep 30, 2021):
Same problem here. Secure input was the culprit and I fixed it by locking/unlocking my Mac server (Windows client).
This isn't Barrier's fault, but a warning would be immensely helpful. Alfred has the same warning too when text snippets don't work.
@tjuerges commented on GitHub (Dec 19, 2021):
Just to add information for others:
In my case (macOS 12.1, Monterey) the same executable was reported as using SecureInput. But in the end the culprit was LastPass.
@wjling commented on GitHub (Apr 6, 2022):
Works for me. Thanks
@sub20hz commented on GitHub (Feb 9, 2023):
If anyone runs into this problem in 2023, there is another possible culprit also related to Barrier's ability to monitor keyboard inputs. Similar to https://github.com/debauchee/barrier/issues/1736, when barrier is updated its possible that permissions are not in effect despite being displayed as enabled in System Preferences. In my case, despite
Privacy & Security -> Input Monitoringdisplaying Barrier as enabled, I had to remove Barrier from this list completely by clicking the minus sign, quitting the app, and then adding Barrier back to this list via the plus sign to finally fix the problem.@lwmcal commented on GitHub (Feb 10, 2023):
This approach works for me. Under Privacy & Security -> Input Monitoring, I originally don't have Barrier on the list. I manually added it and turn it on. It didn't work. I removed it from the list using the minus button. Then restart both computers. Eventually, it works.
@athornton commented on GitHub (Feb 10, 2023):
Although Barrier got kinda Winfax'ed because Apple put Universal Control into the base OS, and it works pretty well.