Barrier: super key (windows key) gets stuck in "pressed" on client

I also have this issue with linux server -> linux client (both Arch). It's oftentimes a stuck super/meta key, but occasionally other modifiers (shift or ctrl). If I experience the problem (let's say its shift for this example), if I restart the barrier server, switch back to the client machine, things are normal. If I immediately switch back to the host, then back to the client, the shift key is stuck again. The modifier stays "stuck" on the client machine's physical keyboard as well. The typical way to resolve this is for me to just reboot the client machine.

Any advice on how I could help debug this would be appreciated as it's driving me absolutely insane. I am able to SSH into the client machine. I've tried DISPLAY=:0 xset -q and DISPLAY=:0 xev to debug and everything seems normal (no held modifiers being shown with xset and the "correct" keys are being pressed (through barrierc or directly) on the client.

This problem exists using Barrier 2.2.0 as well as Synergy 1.10.1.

I'm getting this on practically a daily basis as well. I'm running Arch Linux (recently updated) on both client and server. The problem primarily appears to affect the client, and like Josh, continues even after killing barrier on the client machine.

To fix the problem, I have to log out (to my TTY), log back in and restart X.

I think this is a problem for Windows clients as well and that several different modifier keys can become stuck. If anyone can reproduce it reliably, that would be helpful.

For me, it tends to be the Alt key. I have my environment configured so that Alt is used to move and resize windows (Alt+drag). It's possible it's getting triggered when I alt-drag a window to the edge of the screen (the edge that would normally allow my mouse to move back to the host computer). I'll keep an eye out when I'm moving windows around and see if that has something to do with it (modifier being held when the mouse moves between devices).

I have a meta key stuck using ubuntu server and windows client. At first meta key only works for ubuntu and then doesn' t work for either.

Is there any debugging we can do or logs we can provide that might help get this problem fixed? At this point, I'm contemplating switching to something else because having to close my entire X-window session just to get my keyboard working on a daily basis is not sustainable and the problem seems to be getting worse.

If there is something I can provide, this problem now reliably happens once a day, so I could provide data very quickly and repeatedly.

@DarwinSurvivor - The only thing that I've found to "reset" this (without leaving X) is the following ... and it's not ideal (at all):

#!/usr/bin/env bash

setxkbmap -layout us
xdotool keyup Shift_L Shift_R Control_L Control_R Alt_L Alt_R Super_L Super_R Hyper_L Hyper_R Caps_Lock 204 205 206 207

I've now had this affect non-modifiers somehow.

For example, I use cVim, so "x" is equivalent to "Ctrl+F4" and closes the current tab. I've had the x key get stuck, which means when I switch to a chrome window, it rapid-filer closes all my tabs until the entire window disappears.

My super-key gets stuck like this sometimes. Other keys like x can also get stuck, as DarwinSurvivor mentioned, though those keys always right themselves after a second or two on my machine. I assumed that was caused by (wi-fi) lag since my cursor freezes as well while the client mashes out 'xxxxxxxxx' then stops. The super-key issue seems to be nearly permanent though, outside of restarting X / rebooting.

Server: Windows 10
Client: Linux Mint 19.1 Cinnamon

I get the same with the ALT key.

The behavior becomes inverse. When I press the Alt key on the host then the client behaves like it is not pressed. It happened twice already. I'm not sure what fixed it the first time.

Server: Windows 10
Client: macOS High Sierra 10.13.6

*update:
When the ALT key gets stuck, I can press the CONTROL key to resolve it.

I experience the same (Super key stuck, sometimes the Ctrl key) with a MacOS host and Linux Mint client.

This happens intermittently without known cause, though I observe that it often happens when using Skype or Google Hangout with a head set. To resolve sometimes restarting X helps, sometimes a full shutdown/reboot is needed. setxkbmap / xdotool does not seem to reset.

Server: macOS High Sierra 10.13.6
Client: Linux Mint 18.3
Network: LAN connection to the same switch, same subnet (no Wifi)
Barrier 2.3.2-Release-210c2b70

What in Barrier would cause meta keys to be "pressed" in the client? There must be some event that causes a change of state and then keeps it from getting reset, I presume perhaps naively.

Same problem with Shift key not released from client. I would rename the title as it seems to affect more modifiers than just super key.

Operating Systems
Server: Ubuntu 18.04 (Kernel 4.15.0-99-generic)
Client: Ubuntu 18.04 (Kernel 5.3.0-51-generic)

Barrier Version
Server: barrierc 2.3.2-13-g9080ce45
Client: barriers 2.3.2-13-g9080ce45

Found similar issue in Synergy https://github.com/symless/synergy-core/issues/6459

Small update to make it clear, the unreleased key happens every time I press the shift key so it is unlikely caused by a network issue.

Server: barrier 2.3.2-snapshot-210c2b70 (Windows 10 1909)
Client: barrier 2.3.2-RELEASE-00000000 (Arch Linux up to date, Mate 1.24 over Xorg)

Same, CTRL client stuck on client, pressing CTRL-ALT-DEL while on client invokes Server (Windows)(Lock|SwitchUser|Sign Out|Task Manager) menu, then ESC to go back to desktop un-stucks CTRL on client for a few seconds (20 seconds at most), then it gets stuck again on it's own.

Logs at Debug2 level on both client and server show nothing useful, just the "entering/leaving screen" messages.

Bug makes client pretty unusable, as it interprets simple keystrokes as commands due to ctrl involvement.

I'm experiencing this as well, with both ctrl and alt keys on client getting stuck.
Client and Server are both Ubuntu, both version 2.3.2-snapshot-9080ce45.

Debian 2.1.2+dfsg-1
Shift key pressed on client stops other keys working unless I still have the shift key pressed. e.g. after typing L then I can only type other capital letters.
Moving pointer back to server then back to client resets it.

Happens regularly between my two Linux Mint (20 and 19) computers with Barrier 2.3.3.

Turns out the right shift key gets stuck, labelled SHIFT_R.
A simple press / release of the key resolves the issue.

Stuck keys can be detected this way : xev | grep 'keycode .* (.*)'

In addition to my earlier comment, this happens frequently in connection with either of the following activities, on the Linux client:

• fast window switches (e.g. alt-tab, pressed in fast sequence, i.e. alt-tab / alt-tab / alt tab as opposed to alt-tab-tab-tab). this is intermittent
• using audio or video chat apps like Zoom, Skype, Hangout. this is quite predictable in say 7/10 cases
• being connected to the network over wifi (instead of ethernet)
• switching from wifi connection to ethernet. quite predictable in 8/10 cases.

Once the key got stock (for me it is the Ctrl key), other symptoms start to appear seconds to minutes later like not being able to type random characters in a new terminal window, no caps or no keyboard input at all. Typically the situation gets worse and the only solution is to reboot.

Note it also happens sometimes without any of these activities, but more rarely so.

Client:
Linux 4.15.0-107-generic #108~16.04.1-Ubuntu SMP Fri Jun 12 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Barrier 2.3.2-snapshot-210cb270
Build Date: Friday June 5 2020

Server:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: Wed May 27 17:00:02 PDT 2020; root:xnu 4570.71.80.1~1/RELEASE_X86_64 x86_64
Barrier: 2.3.2-Release-210cb270
Build Date: 3 October 2019

Network: Ethernet, 1GB, same subnet, sometimes wifi (barrier und client are on the same router, however server is connected via ethernet, client via wifi)

Updated

26 Aug 2020 - added wifi connection as a contributor to frequency
28 Aug 2020 - added wifi to ethernet switch as a contributor to frequency

Running into this problem today, I think I can reproduce it fairly regularly. Trying to narrow down exact steps.

What I have so far is this:

1. Assign a shortcut to start barrier on the client (I used CTRL-ALT-SHIFT-F9)
2. Start barrier using the shortcut with secondary keyboard directly connected to client (note it was not running before this)
3. Switch screen to the client with primary keyboard connected to server (using a barrier shortcut, CTRL-ALT-SHIFT-F12)
4. Press any modifier key on the server keyboard (actually not necessary, but causes xkbwatch to update)

I found that, at least at one point, I had multiple barrier processes running (not barrierc, but barrier), on the Linux client. I'm going to restart everything fresh and see if I can narrow down a set of steps that reproduces the problem cleanly.

OK, I did some more testing that reliably reproduces the problem:

Client and Server in this case refer to barrier setup only.
Linux server has a secondary pair of keyboard+mouse.
Primary keyboard and mouse are connected to windows machine.
Except where noted, all operations are performed on the primary keyboard + mouse

1. Reboot both Linux Client and Window Server machines
2. Login to Linux (using secondary keyboard + mouse)
3. Login to Windows
4. SSH into Linux from Windows
  - "ps axu | grep -i barrier"
  - No barrier processes running
5. DISPLAY=:1 xkbwatch &
6. On secondary keyboard, press and release each modifier key, one at a time, and confirm xkbwatch shows them correctly
  - Also note the "super" key notably does it's normal action
7. On secondary keyboard, press CTRL-ALT-SHIFT-F9 shortcut to run barrier
  - "ps axu | grep -i barrier"
  - Output shows "barrier" and "/usr/bin/barrierc ..." both running
8. On secondary keyboard, again press and release each modifier key (SUCCESS)
9. Start Barrier Server on Windows machine
10. On secondary keyboard, again press and release each modifier key again (SUCCESS)
11. Switch primary keyboard to Linux screen by pressing CTRL-ALT-SHIFT-F12 shortcut
12. Press and release CTRL then ALT (FAIL)
  *** At this time, the xkbwatch window shows modifiers stuck for ALT and CTRL
13. Switch primary keyboard to Windows screen by pressing CTRL-ALT-SHIFT-F12 shortcut
14. On secondary keyboard, again press and release each modifier key again - modifiers rest correctly (SUCCESS)
15. Kill "barrier" and "barrierc" processing on the Linux client
16. On secondary keyboard, press CTRL-ALT-SHIFT-F9 shortcut to run barrier again
17. On secondary keyboard, again press and release each modifier key again (SUCCESS)
18. Switch primary keyboard back to Linux screen by pressing CTRL-ALT-SHIFT-F12 shortcut
19. Press ALT key on primary keyboard
  * CTRL and SHIFT key modifiers are now stuck
20. Switch primary keyboard back to Windows screen by pressing CTRL-ALT-SHIFT-F12 shortcut again
21. On secondary keyboard, again press and release each modifier key again - modifiers stay stuck this time (FAIL)

If you read through this carefully, you will find I was able to recover one time, but a second time, it did not recover.

The odd thing is that it's the ALT key that seems to trigger it, even though, in this attempt, the CTRL and SHIFT keys were the ones that got stuck. I also found that using xdotool to reset modifiers works, but I had trouble getting ALT to clear until I used the following command-line, copied from @joshskidmore above, which appears to do the job (note I have to login via SSH to run this since the stuck modifiers make it impossible to run commands directly on the ubuntu machine):

xdotool keyup Shift_L Shift_R Control_L Control_R Alt_L Alt_R Super_L Super_R Hyper_L Hyper_R Caps_Lock 204 205 206 207

Thank you @joshskidmore!

Also note that this time, there was never a duplicate barrier process detected on the Linux client.

Another data-point: using SSH to login to the linux machine and start barrier, the problem does not happen.

Hmm, and another data-point: using SSH to login to the linux machine and start barrier, WHILE holding down CTRL-ALT-SHIFT on the secondary usb keyboard (directly connected to the linux machine), DOES reproduce the problem.

I can now reliably reproduce the problem:

1. linux client (laptop), macos server - client is connected successfully to server (LAN network). works without problems for any amount of time
2. hot-unplug laptop, on the move. at some point turn on wifi and work directly on built-in keyboard & mouse (that is, no connection to the barrier server is possible, different network)
3. plug back to docking station again, wifi still turned on, barrier connects back to server just fine
4. a few keystrokes & mouse clicks on, weird things start to happen. ctrl key is stuck. typing closes or opens windows at will (probably some ctrl+key combination), even mouse clicks fail to accomplish the expected (e.g. impossible to close a window or open a new tab in Chrome).

Only rebooting solves the problem.

Note: this does not happen when barrier is not running. I conclude that it is not a Linux/hardware issue.

Client:
Linux 4.15.0-107-generic #108~16.04.1-Ubuntu SMP Fri Jun 12 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Barrier 2.3.2-snapshot-210cb270
Build Date: Friday June 5 2020

Server:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: Wed May 27 17:00:02 PDT 2020; root:xnu 4570.71.80.1~1/RELEASE_X86_64 x86_64
Barrier: 2.3.2-Release-210cb270
Build Date: 3 October 2019

When it happened to me, I wasn't plugging or unplugging anything. Both laptops stayed on WiFi throughout (unless there were some silent disconnections and reconnections that I'm not aware of - but I have no reason to suspect any silent disconnections.

I have the same problem as you that makes barrier unusable ... :'(