[GH-ISSUE #207] super key (windows key) gets stuck in "pressed" on client

gitea-mirror commented

2026-05-05 05:29:26 -06:00

Owner

Originally created by @exodist on GitHub (Dec 23, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/207

Operating Systems

Arch Linux

Barrier Version

2.1.0

Steps to reproduce bug

Connect one arch client to one arch server
Wait, using super key occasionally
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.
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.

Originally created by @exodist on GitHub (Dec 23, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/207 ### 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.

gitea-mirror added the

bug

linux

labels 2026-05-05 05:29:26 -06:00

gitea-mirror commented

2026-05-05 05:29:30 -06:00

Author

Owner

@joshskidmore commented on GitHub (Mar 18, 2019):

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.

@joshskidmore commented on GitHub (Mar 18, 2019): 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.

gitea-mirror commented

2026-05-05 05:29:33 -06:00

Author

Owner

@DarwinSurvivor commented on GitHub (May 1, 2019):

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.

@DarwinSurvivor commented on GitHub (May 1, 2019): 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.

gitea-mirror commented

2026-05-05 05:29:35 -06:00

Author

Owner

@noisyshape commented on GitHub (May 1, 2019):

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.

@noisyshape commented on GitHub (May 1, 2019): 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.

gitea-mirror commented

2026-05-05 05:29:37 -06:00

Author

Owner

@DarwinSurvivor commented on GitHub (May 1, 2019):

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

@DarwinSurvivor commented on GitHub (May 1, 2019): 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).

gitea-mirror commented

2026-05-05 05:29:39 -06:00

Author

Owner

@xgdgsc commented on GitHub (Jul 21, 2019):

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.

@xgdgsc commented on GitHub (Jul 21, 2019): 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.

gitea-mirror commented

2026-05-05 05:29:42 -06:00

Author

Owner

@DarwinSurvivor commented on GitHub (Oct 16, 2019):

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

gitea-mirror commented

2026-05-05 05:29:45 -06:00

Author

Owner

@joshskidmore commented on GitHub (Oct 16, 2019):

@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

@joshskidmore commented on GitHub (Oct 16, 2019): @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 ```

gitea-mirror commented

2026-05-05 05:29:50 -06:00

Author

Owner

@DarwinSurvivor commented on GitHub (Oct 28, 2019):

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.

@DarwinSurvivor commented on GitHub (Oct 28, 2019): 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.

gitea-mirror commented

2026-05-05 05:29:52 -06:00

Author

Owner

@gwyker commented on GitHub (Nov 7, 2019):

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

@gwyker commented on GitHub (Nov 7, 2019): 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

gitea-mirror commented

2026-05-05 05:29:54 -06:00

Author

Owner

@itutto commented on GitHub (Nov 14, 2019):

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.

@itutto commented on GitHub (Nov 14, 2019): 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.

gitea-mirror commented

2026-05-05 05:29:57 -06:00

Author

Owner

@miraculixx commented on GitHub (Nov 21, 2019):

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.

@miraculixx commented on GitHub (Nov 21, 2019): 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.

gitea-mirror commented

2026-05-05 05:30:00 -06:00

Author

Owner

@axtux commented on GitHub (May 19, 2020):

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 commented on GitHub (May 19, 2020): 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

gitea-mirror commented

2026-05-05 05:30:03 -06:00

Author

Owner

@axtux commented on GitHub (May 19, 2020):

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

@axtux commented on GitHub (May 19, 2020): Found similar issue in Synergy https://github.com/symless/synergy-core/issues/6459

gitea-mirror commented

2026-05-05 05:30:05 -06:00

Author

Owner

@axtux commented on GitHub (May 22, 2020):

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.

@axtux commented on GitHub (May 22, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:08 -06:00

Author

Owner

@Cloudbyte-Pony commented on GitHub (Jun 10, 2020):

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.

@Cloudbyte-Pony commented on GitHub (Jun 10, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:11 -06:00

Author

Owner

@mikmorg commented on GitHub (Jun 10, 2020):

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.

@mikmorg commented on GitHub (Jun 10, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:15 -06:00

Author

Owner

@richwalker commented on GitHub (Jul 2, 2020):

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.

@richwalker commented on GitHub (Jul 2, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:17 -06:00

Author

Owner

@AdrianDC commented on GitHub (Jul 24, 2020):

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

@AdrianDC commented on GitHub (Jul 24, 2020): 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 .* (.*)'`

gitea-mirror commented

2026-05-05 05:30:20 -06:00

Author

Owner

@miraculixx commented on GitHub (Jul 28, 2020):

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

@miraculixx commented on GitHub (Jul 28, 2020): In addition to my earlier [comment](https://github.com/debauchee/barrier/issues/207#issuecomment-556559113), 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

gitea-mirror commented

2026-05-05 05:30:22 -06:00

Author

Owner

@artnaseef commented on GitHub (Aug 12, 2020):

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:

Assign a shortcut to start barrier on the client (I used CTRL-ALT-SHIFT-F9)
Start barrier using the shortcut with secondary keyboard directly connected to client (note it was not running before this)
Switch screen to the client with primary keyboard connected to server (using a barrier shortcut, CTRL-ALT-SHIFT-F12)
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 commented on GitHub (Aug 12, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:24 -06:00

Author

Owner

@artnaseef commented on GitHub (Aug 12, 2020):

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 commented on GitHub (Aug 12, 2020): OK, I did some more testing that <mostly> 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.

gitea-mirror commented

2026-05-05 05:30:25 -06:00

Author

Owner

@artnaseef commented on GitHub (Aug 12, 2020):

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.

@artnaseef commented on GitHub (Aug 12, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:28 -06:00

Author

Owner

@miraculixx commented on GitHub (Oct 31, 2020):

I can now reliably reproduce the problem:

linux client (laptop), macos server - client is connected successfully to server (LAN network). works without problems for any amount of time
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)
plug back to docking station again, wifi still turned on, barrier connects back to server just fine
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 workaround in relation to suspend mode (which disrupts the network connection). 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 workaround on suspend, see https://gist.github.com/miraculixx/4cfb26cad33943f90742ad98b4ce9f87

Updated 09.2024:
Ever since I have employed this workaround (to kill barrier whenever the network is disconnected, such as on entering sleep), the frequency of the stuck keys issue has gone away almost completely. The only time I can see it happening now is when there is a network issue of some kind or when the system is overloaded.

@miraculixx commented on GitHub (Oct 31, 2020): 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 workaround in relation to suspend mode (which disrupts the network connection). 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 workaround on suspend, see https://gist.github.com/miraculixx/4cfb26cad33943f90742ad98b4ce9f87 Updated 09.2024: Ever since I have employed this workaround (to kill barrier whenever the network is disconnected, such as on entering sleep), the frequency of the stuck keys issue has gone away almost completely. The only time I can see it happening now is when there is a network issue of some kind or when the system is overloaded.

gitea-mirror commented

2026-05-05 05:30:31 -06:00

Author

Owner

@elicoten commented on GitHub (Oct 31, 2020):

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.

@elicoten commented on GitHub (Oct 31, 2020): 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.

gitea-mirror commented

2026-05-05 05:30:33 -06:00

Author

Owner

@cvalentin-adeo commented on GitHub (Nov 2, 2020):

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

@cvalentin-adeo commented on GitHub (Nov 2, 2020): I have the same problem as you that makes barrier unusable ... :'(

gitea-mirror commented

2026-05-05 05:30:36 -06:00

Author

Owner

@501st-alpha1 commented on GitHub (Nov 2, 2021):

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

@501st-alpha1 commented on GitHub (Nov 2, 2021): 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.)

gitea-mirror commented

2026-05-05 05:30:39 -06:00

Author

Owner

@geolaw commented on GitHub (Jan 26, 2022):

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.

@geolaw commented on GitHub (Jan 26, 2022): 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.

gitea-mirror commented

2026-05-05 05:30:41 -06:00

Author

Owner

@mirh commented on GitHub (Feb 28, 2022):

https://github.com/symless/synergy-core/issues/4493
I, for one, am getting scroll lock stuck which makes for all the kind of consequent issues https://github.com/debauchee/barrier/issues/102 https://github.com/debauchee/barrier/issues/1291

@mirh commented on GitHub (Feb 28, 2022): https://github.com/symless/synergy-core/issues/4493 I, for one, am getting scroll lock stuck which makes for all the kind of consequent issues https://github.com/debauchee/barrier/issues/102 https://github.com/debauchee/barrier/issues/1291

gitea-mirror commented

2026-05-05 05:30:44 -06:00

Author

Owner

@Sakata-MC commented on GitHub (Apr 18, 2023):

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.

@Sakata-MC commented on GitHub (Apr 18, 2023): 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.

gitea-mirror commented

2026-05-05 05:30:46 -06:00

Author

Owner

@TIAcode commented on GitHub (Jan 8, 2024):

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)

@TIAcode commented on GitHub (Jan 8, 2024): 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) ```

gitea-mirror commented

2026-05-05 05:30:50 -06:00

Author

Owner

@bkowenswork commented on GitHub (Jun 11, 2024):

I've tested this on my Ubuntu 22.04 and have spotted this behavior on XFCE, KDE and Gnome. There isn't an obvious trigger, it can take days or weeks to happen or it can happen twice in the same day.

@bkowenswork commented on GitHub (Jun 11, 2024): I've tested this on my Ubuntu 22.04 and have spotted this behavior on XFCE, KDE and Gnome. There isn't an obvious trigger, it can take days or weeks to happen or it can happen twice in the same day.

gitea-mirror commented

2026-05-05 05:30:51 -06:00

Author

Owner

@ohel commented on GitHub (Sep 24, 2024):

I've had the same problem for a couple of years. It used to resolve itself by just pressing the stuck key and releasing it physically, and the problem didn't occur frequently at all. The stuck key might've been Super, but also Ctrl, Alt or Shift.

But now recently I've had the Super key stuck on client almost all the time. Using "xdotool key --clearmodifiers Escape" along with restarting the barrier client helps to get the Super key unstuck via SSH, but it gets stuck again if I press it. My client is Gentoo, server has been Ubuntu 22.04 and now 24.04.

Edit: I just noticed when the Super key gets stuck and if I do the xdotool trick, keyboard works. But, immediately if my mouse pointer visits the server's display and goes back to the client, the Super key is stuck again on client. Stopping and starting the barrier server also resets the key, but again, it's enough for my mouse pointer to visit the server's screen and Super is stuck on client - even if I restart both the barrier server and client.

@ohel commented on GitHub (Sep 24, 2024): I've had the same problem for a couple of years. It used to resolve itself by just pressing the stuck key and releasing it physically, and the problem didn't occur frequently at all. The stuck key might've been Super, but also Ctrl, Alt or Shift. But now recently I've had the Super key stuck on client almost all the time. Using "xdotool key --clearmodifiers Escape" along with restarting the barrier client helps to get the Super key unstuck via SSH, but it gets stuck again if I press it. My client is Gentoo, server has been Ubuntu 22.04 and now 24.04. Edit: I just noticed when the Super key gets stuck and if I do the xdotool trick, keyboard works. But, immediately if my mouse pointer visits the server's display and goes back to the client, the Super key is stuck again on client. Stopping and starting the barrier server also resets the key, but again, it's enough for my mouse pointer to visit the server's screen and Super is stuck on client - even if I restart both the barrier server and client.

gitea-mirror commented

2026-05-05 05:30:54 -06:00

Author

Owner

@miraculixx commented on GitHub (Sep 25, 2024):

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.

Wifi can show intermittent connection issues such as varying speeds and can be causing timeouts for barrier that are not perceptible to a user. I have found that stuck key issues frequently happen when barrier is connected via WLAN, however do not occur with wired connections on my local network.

@miraculixx commented on GitHub (Sep 25, 2024): > 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. Wifi can show intermittent connection issues such as varying speeds and can be causing timeouts for barrier that are not perceptible to a user. I have found that stuck key issues frequently happen when barrier is connected via WLAN, however do not occur with wired connections on my local network.

gitea-mirror commented

2026-05-05 05:30:56 -06:00

Author

Owner

@cephcyn commented on GitHub (Nov 5, 2025):

Adding a comment to note that this is also a frequent issue for me.
I am usually using Windows 10 host, Ubuntu 24.04 client, connected via WLAN, and have experienced Super, Shift, and Ctrl keys stuck at varying times. Sometimes this is shortly after resuming from suspend, sometimes this is mid-session (maybe the router had a hiccup).

@cephcyn commented on GitHub (Nov 5, 2025): Adding a comment to note that this is also a frequent issue for me. I am usually using Windows 10 host, Ubuntu 24.04 client, connected via WLAN, and have experienced Super, Shift, and Ctrl keys stuck at varying times. Sometimes this is shortly after resuming from suspend, sometimes this is mid-session (maybe the router had a hiccup).

gitea-mirror commented

2026-05-05 05:30:58 -06:00

Author

Owner

@nbolton commented on GitHub (Nov 5, 2025):

Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork).

https://github.com/deskflow/deskflow
https://github.com/input-leap/input-leap

If this is still an issue in those projects, we would appreciate a cross-post of this issue.

@nbolton commented on GitHub (Nov 5, 2025): Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork). https://github.com/deskflow/deskflow https://github.com/input-leap/input-leap If this is still an issue in those projects, we would appreciate a cross-post of this issue.

Rows
Columns

[GH-ISSUE #207] super key (windows key) gets stuck in "pressed" on client #169

Operating Systems

Barrier Version

Steps to reproduce bug

Other info