github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #129] Loss of keyboard input on Windows client while mouse input still correctly interpreted #101

New issue

Open

opened 2026-05-05 05:16:03 -06:00 by gitea-mirror · 10 comments

gitea-mirror commented

2026-05-05 05:16:03 -06:00

Owner

Originally created by @IWasHere2 on GitHub (Sep 13, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/129

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

Connect Windows client to Mac server
Highlight some text on the Mac and use Apple-C or right-click to copy to the clipboard.
Move the mouse to the Windows screen. Open a text application with the mouse via the start menu, and start typing.
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!!!

Originally created by @IWasHere2 on GitHub (Sep 13, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/129 ### 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!!! `

gitea-mirror added the

macOS

bug

windows

labels 2026-05-05 05:16:03 -06:00

gitea-mirror commented

2026-05-05 05:16:07 -06:00

Author

Owner

@rpatterson commented on GitHub (Feb 20, 2019):

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 commented on GitHub (Feb 20, 2019): 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.

gitea-mirror commented

2026-05-05 05:16:09 -06:00

Author

Owner

@rpatterson commented on GitHub (Feb 20, 2019):

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.

@rpatterson commented on GitHub (Feb 20, 2019): 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.

gitea-mirror commented

2026-05-05 05:16:10 -06:00

Author

Owner

@ericobi commented on GitHub (Sep 13, 2020):

same here! not working...

@ericobi commented on GitHub (Sep 13, 2020): same here! not working...

gitea-mirror commented

2026-05-05 05:16:12 -06:00

Author

Owner

@rodfersou commented on GitHub (Mar 6, 2021):

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!

@rodfersou commented on GitHub (Mar 6, 2021): 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!

gitea-mirror commented

2026-05-05 05:16:14 -06:00

Author

Owner

@alexanderphoenix commented on GitHub (Sep 13, 2021):

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.

@alexanderphoenix commented on GitHub (Sep 13, 2021): 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.

gitea-mirror commented

2026-05-05 05:16:15 -06:00

Author

Owner

@arminanton commented on GitHub (Jul 8, 2022):

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 commented on GitHub (Jul 8, 2022): 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)

gitea-mirror commented

2026-05-05 05:16:16 -06:00

Author

Owner

@arminanton commented on GitHub (Jul 19, 2022):

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

@arminanton commented on GitHub (Jul 19, 2022): 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

gitea-mirror commented

2026-05-05 05:16:18 -06:00

Author

Owner

@zenfish commented on GitHub (Oct 6, 2022):

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.

@zenfish commented on GitHub (Oct 6, 2022): 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.

gitea-mirror commented

2026-05-05 05:16:20 -06:00

Author

Owner

@farraherbg commented on GitHub (Mar 30, 2023):

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.

@farraherbg commented on GitHub (Mar 30, 2023): 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.

gitea-mirror commented

2026-05-05 05:16:24 -06:00

Author

Owner

@YingWANG0909 commented on GitHub (May 22, 2024):

@arminanton thank you so much!!

@YingWANG0909 commented on GitHub (May 22, 2024): @arminanton thank you so much!!