Loss of keyboard input on Windows client while mouse input still correctly interpreted

[IWasHere2]

Operating Systems

Server: Mac OSX on 10.13.6 (High Sierra)
Client: Windows 10 on Version 1709 (Build 16299.402)

Barrier Version

Mac: 2.1.0-RELEASE-8b69f9fe
Windows: 2.1.0-RELEASE-0b2dfd80

Steps to reproduce bug

1. Connect Windows client to Mac server
2. Highlight some text on the Mac and use Apple-C or right-click to copy to the clipboard.
3. Move the mouse to the Windows screen. Open a text application with the mouse via the start menu, and start typing.
4. Observe that keyboard input is still being directed to the Mac applications, and that no keyboard input is being processed on the Windows side.

If this doesn't happen the first time, repeat steps 2-4 a few times.

Other info

Disabling the clipboard in Server settings does not make the problem go away. However, whether that checkbox is properly respected is questionable, as it resulted in the following curious debug log output, where you can see that despite being disabled, clipboard-related code is still executing:

[2018-09-13T14:12:16] NOTE: clipboard sharing is disabled [2018-09-13T14:12:16] DEBUG: clipboard changed: barrier owned [2018-09-13T14:12:16] DEBUG: desk Default window is 0x000c00b2 [2018-09-13T14:12:16] DEBUG: switched to desk "Default" [2018-09-13T14:12:16] DEBUG: desktop is now accessible [2018-09-13T14:12:16] DEBUG: open clipboard [2018-09-13T14:12:16] DEBUG: empty clipboard [2018-09-13T14:12:16] DEBUG: close clipboard [2018-09-13T14:12:16] DEBUG: open clipboard [2018-09-13T14:12:16] DEBUG: empty clipboard [2018-09-13T14:12:16] DEBUG: close clipboard

Another potentially related condition: The Mac server was running on a Macbook with all three of (1) builtin keyboard (2) wired keyboard and (3) bluetooth keyboard active at any given time. The Windows client had no keyboards nor mice connected at the time the bug exhibited.

Workaround #1: Restarting the server and/or client brings the keyboard back to life (whether which one, or both, needs to be restarted is not consistent).

Workaround #2: This bug does not exhibit when using a Windows server with a Mac client.

The normal log on the Mac also shows many of these warning messages, unknown if related but seems suspicious given the observed non-deterministic behavior in workaround #1:
pid(67177)/euid(1901998861) is calling TIS/TSM in non-main thread environment, ERROR : This is NOT allowed. Please call TIS/TSM in main thread!!!

[rpatterson]

This is happening here as well. It was working just fine with an Ubuntu 19.04 server and a Windows 10 client until I just ran apt dist-upgrade after which I started having this problem. I've restarted both machines and restarted barrier itself on both ends multiple time with no apparent change in behavior.

It also appears inconsistent. I'm pretty sure at one point the arrow keys were not working but now they appear to be working. The return, windows, and alt-tab keys haven't worked at all. Normal letter keys seem to work fine.

[rpatterson]

Apologies and please disregard, that upgrade switched the default session to Wayland. Once I switched back to X, the keyboard worked fine again. See #247 and #109.

[ericobi]

same here! not working...

[rodfersou]

found the culprit here, in my case was Bitwarden app that was making my keyboard don't work in the other machine.

Turned it off and everything works again.

So check if you installed some new app recently, try to remove any new app running and see if barrier start to work as expected!

[alexanderphoenix]

Thank you @rodfersou, turns out Bitwarden was the problem for me also.
When I close Bitwarden then the keyboard starts working on the client windows PC.

Unfortunately removing Bitwarden isn't an option for me, and the desktop client has to remain active as I use it often and the fingerprint login is so useful!
Any idea of how I could have my cake and eat it too, meaning using both Bitwarden and Barrier at the same time?

Happy to help troubleshoot if anyone has ideas.
First time using a mac, but never had problems with Barrier on the Linux laptop I was using until a week ago.
...then again I wasn't using Bitwarden's desktop app then.

[arminanton]

Running Big Sur Barrier server and Windows 11 Barrier client. Using SSL on both sides. The mouse works fine, but the keyboard does not work anymore. Probably company's firewall is blocking some of its communication. I'm not able to request it to be whitelisted. Could you provide an option to modify the path used? I tried changing the default port to something else, but still, only the mouse passes through. I can share logs from both sides if needed. (I'm a dev as well)

[arminanton]

Your Mac probably has a service or app that left Secure Input active (used to protect you when entering passwords). To check if any app is using secure input, run: ioreg -l -w 0 | grep SecureInput. If you see anything other than blank/empty, that means there is a app/service (or many) with such feature activated.

https://www.nickjvturner.com/blog/2020/08/20/secure-input-mode

[zenfish]

This found the culprit on my mac (Catalina, ymmv) -

for pid in $(ioreg -l -w 0 | grep SecureInput | sed -e 's/^.*PID"=//' -e 's/,.*$//'|sort -u); do ps -p $pid -c -o args=; done

Turns out damn iterm2 was the culprit; disabling "Secure Keyboard Entry" in the root menu made barrier work again.

Might be nice to check for something like this on startup? Took me far too long to find this issue.

[farraherbg]

I also had this issue on OSX. @arminanton's ioreg invocation found the culprit - it was /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow console which I didn't quite understand since I was logged in.

I locked screen and logged in and ioreg then gave no results, problems solved.

[YingWANG0909]

@arminanton thank you so much!!