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

[exodist]

Operating Systems

Arch Linux

Barrier Version

2.1.0

Steps to reproduce bug

1. Connect one arch client to one arch server
2. Wait, using super key occasionally
3. Client eventually gets stuck with mod key pressed, nothing will make it un-press for long, control+alt+delete followed by escape does, but then it auto-presses again a few seconds later.
4. Cannot type in terminal or click on things as many keys and clicks are special when combined with the super key.

Other info

This is 2 fresh barrier installs on 2 fresh arch linux installs. Both are using awesome windows manager which uses the super key heavily. It works for a few seconds, but then gets stuck in down position, even if you do not do anything. rebooting is the only way to make it stop, even killing the barrier client does not make the keypress stop. Keypress never starts or gets stuck if barrier is never loaded.

[joshskidmore]

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.

[DarwinSurvivor]

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.

[noisyshape]

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.

[DarwinSurvivor]

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).

[xgdgsc]

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.

[DarwinSurvivor]

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.

[joshskidmore]

@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

[DarwinSurvivor]

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.

[gwyker]

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

[itutto]

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.

[miraculixx]

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.

[axtux]

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

[axtux]

Found similar issue in Synergy symless#6459

[axtux]

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.

[Cloudbyte-Pony]

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.

[mikmorg]

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.

[richwalker]

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.

[AdrianDC]

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 .* (.*)'

[miraculixx]

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)

Workaround

I may have found a work around in relation to suspend mode (which disrupts the network connection), still testing as of writing this. The investigation shows that the stuck key starts to happen right after the network disruption has been fixed and barrier reconnects automatically. When barrier is stopped before the network disruption (e.g. on suspend) and is restarted only after the network is ok again, there does not seem to be a stuck key. Perhaps this hints to an issue in barriers network / reconnection handling?

For the work around on suspend, see https://gist.github.com/miraculixx/4cfb26cad33943f90742ad98b4ce9f87

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
15 Feb 2022 - may have found a work around

[artnaseef]

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.

[artnaseef]

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.

[artnaseef]

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.

[miraculixx]

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

Updated:
With Client 2.3.3-release-3395-cca9 (Build Date November 10, 2020) this is 100% reproducible by disconnecting the still running client from the server for a couple of hours, then reconnecting. Every single time the client's ctrl key is "stuck" afterwards and the only remedy is to reboot.

Workaround

I may have found a work around in relation to suspend mode (which disrupts the network connection), still testing as of writing this. The investigation shows that the stuck key starts to happen right after the network disruption has been fixed and barrier reconnects automatically. When barrier is stopped before the network disruption (e.g. on suspend) and is restarted only after the network is ok again, there does not seem to be a stuck key. Perhaps this hints to an issue in barriers network / reconnection handling?

For the work around on suspend, see https://gist.github.com/miraculixx/4cfb26cad33943f90742ad98b4ce9f87

[elicoten]

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.

[cvalentin-adeo]

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

[501st-alpha1]

I ran into this problem too; it definitely happened with Alt, Shift, and Control, probably Super, and I'm pretty sure even Enter at least once. My Barrier server is running on Debian, Barrier version 2.2.0, and the client in question is Pop! OS, with Barrier version 2.3.3. Interestingly, I also have another Debian client (different version of Debian from the server, not sure which version of Barrier), but I haven't had the problem there. I also haven't noticed the problem on my Windows client (Barrier version 2.3.3-release-3395cca9). All four devices are connected via. Ethernet to the same router, and I wasn't doing anything with external keyboards, so I don't think either of those factors apply to me.

I was sometimes able to fix the issue by pressing the stuck keys again, but I've had varying success with that, and also it can be hard to tell which key is stuck. The script provided by @joshskidmore fixes the issue (thanks!) and unsticks any keys, at least until the next time it happens. I usually keep SSH (+ Mosh) sessions open between my devices anyway, so I'll be keeping that script handy. (And it does have to be SSH, because sometimes the stuck keys will mean I'm unable to trigger the script directly on the client.)

[geolaw]

I'm also seeing this issue which seriously has had me scratching my head and wondering WTF is going on.

I am currently running barrier on fedora and RHEL8 :

$ rpm -qa |grep barrier ; ssh rhlaptop rpm -qa |grep barrier
barrier-2.3.3-4.fc35.x86_64
barrier-2.3.3-2.epel8.playground.x86_64

Ubuntu and Regolith were also previously in the mix as well as Synergy 1.14 -
synergy_1.14.0-stable.67d824b8.el8.rpm
On RHEL8 synergy was not working properly which made me switch to barrier.
I previously had been a paid synergy supporter going back probably close to 10 years. Finding
this bug report makes me wonder really how long this has been going on because I swear I've
had this issue forever.

Anyway, My problem normally manifests itself when I am clicking in a web browser on a client.
Clicking a login button that usually just opens within the same tab will often open a new tab

sometimes I can tap on the various keys, ctrl, alt, meta, etc and it will "unstick" but other times
I can usually mouse back to the server machine and then back and its fine.

I'm not using the GUI "barrer" - calling barrierc / barriers directly from my i3 start up scripts.

I can enable debug logging and things if needed.

[mirh]

symless#4493
I, for one, am getting scroll lock stuck which makes for all the kind of consequent issues #102 #1291

[Sakata-MC]

I get this when using my Windows host and Linux client as well. I use a G-key macro to switch computers, "Alt+Control+Shift+{" and "Alt+Control+Shift+}" for switch to main and switch to client, respectively. I use the RIGHT modifier keys for my macros.

Never gets stuck coming back to windows, but often gets stuck on client.

For myself, if I press and release the RIGHT control/alt/shift keys (whichever I see is stuck) then I can continue along fine, it's just more of an annoyance for me.

[TIAcode]

Same problem, two Arch Linuxes with headless barrier. Always the windows key. xdotool works, thanks for that!

Running xmodmap over ssh when the keys were stuck I got these messages, last two times it has been the same combination of keys. I'm wondering if I could detect the one of the keys being stuck for a while and run that xdotool command automatically.

xmodmap:  please release the following keys within 2 seconds:
    Super_R (keysym 0xffec, keycode 134)
    UNNAMED (keysym 0x0, keycode 206)
xmodmap:  please release the following keys within 4 seconds:
    Super_R (keysym 0xffec, keycode 134)
    UNNAMED (keysym 0x0, keycode 206)
xmodmap:  please release the following keys within 8 seconds:
    Super_R (keysym 0xffec, keycode 134)
    UNNAMED (keysym 0x0, keycode 206)
xmodmap:  please release the following keys within 16 seconds:
    Super_R (keysym 0xffec, keycode 134)
    UNNAMED (keysym 0x0, keycode 206)