mirror of
https://github.com/debauchee/barrier.git
synced 2026-05-15 14:16:02 -06:00
[GH-ISSUE #393] Keyboard not being shared since macOS update (10.14.6 (18G87)) #311
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#311
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 @domparry on GitHub (Aug 7, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/393
Operating Systems
Server: macOS Mojave 10.14.6 (18G87)
Client: macOS High Sierra 10.13.6
Barrier Version
2.1.0 and 2.3.0
Steps to reproduce bug
Other info
@domparry commented on GitHub (Aug 19, 2019):
Just as an update, I've tested this on 2.3.1 and it still persists.
@domparry commented on GitHub (Aug 30, 2019):
Something I see in the logs when I switch to the other machine:
@AdrianKoshka commented on GitHub (Aug 30, 2019):
That's a long-time warning, iirc it's doesn't interfere with anything.
@bookshelfdave commented on GitHub (Sep 2, 2019):
I'm experiencing the same issue. I added a bunch of traces throughout the source to log events (EventQueue, OSXKeyState, OSXScreen etc), and it appears that only mouse events are being fired. If anyone has pointers on where I should be looking in the source, I'd be happy to debug some more.
@domparry commented on GitHub (Sep 3, 2019):
Any work around on your side to get it going again @metadave ?
@jbirthisel commented on GitHub (Sep 5, 2019):
This is happening to me off and on all the time.
Example: Today quit working in morning. Reset both server and client side. Rebooted client even. No fix. Then 5 minutes ago (14:00) the keyboard just started working again.
@bookshelfdave commented on GitHub (Sep 5, 2019):
not yet, still debugging and learning about iokit. All signs currently point to keyboard events not being fired on the server.
edit:
control/option/command appear to fire events, letter/number keys do not
@noisyshape commented on GitHub (Sep 6, 2019):
I couldn't reproduce this with VMware guests and I'm not seeing any difference in behavior with 10.14.6. This may be identical to https://github.com/symless/synergy-core/issues/6513 where supposedly it's something to do with input source settings.
When all else fails, post full debug logs.
@domparry commented on GitHub (Sep 8, 2019):
I've double checked the keyboard input source settings as described in that issue, and that's not the case here. @noisyshape When you say full debug logs, are you referring to something more than the logs shown from the
show logfunction? If there's a way to turn on more detailed logs, let me know and I'll happily do so.@noisyshape commented on GitHub (Sep 9, 2019):
@domparry In the settings dialog (F4) there is a logging level option. Set it to Debug2 and restart the client/server. If you can log a short session with a couple of failed keystrokes that could be helpful. You can use pastebin for this.
@domparry commented on GitHub (Sep 9, 2019):
*** Edit - I didn't restart barrier after setting the debug level, so re-pasting the logs ***
Here you go @noisyshape . I've included both the client and server logs below.
Client Log: https://pastebin.com/EcCyjHMR
Server Log:https://pastebin.com/1VwreTTK
@domparry commented on GitHub (Sep 13, 2019):
Please let me know if there is anything else I can provide to help find the cause of this. It essentially makes barrier unusable.
@bookshelfdave commented on GitHub (Sep 17, 2019):
As barrier and synergy aren't working for me because of this bug, I tried using https://www.sharemouse.com/. It has the same problem with keyboard sharing, _however, it also shows an orange icon when running that says "Keyboard not working?". Clicking on the icon takes you to the ShareMouse support page that describes apps that leave MacOS Secure Input enabled.
tl;dr I started killing apps until my keyboard worked again. Some possibly useful info here and here.
also, props to the sharemouse folks for showing that helpful warning.
edit - I should mentioned that I think Evernote is the culprit, but I'll have to observe over a few days to verify.edit: one more doc that's helpful
cc @domparry
@domparry commented on GitHub (Sep 17, 2019):
@metadave, you're awesome. Spot on. My issue was secureinput locked by a startup app (workflowy). Huge Thank you.
@domparry commented on GitHub (Sep 25, 2019):
I'm closing this because it's solved (And not a Barrier issue)
@iulo commented on GitHub (Nov 23, 2020):
@metadave thanks bro, save my life.
for other who face on this problem, a possiable solution is just: locking and unlocking your system.
@royriojas commented on GitHub (Dec 4, 2020):
This is the simplest solution so far... many many thanks @iulo
@shabeer commented on GitHub (May 17, 2023):
thanks @iulo for the quick solution