Barrier: 超级键（Windows键）在客户端上“卡住”

我在linux服务器-> linux客户端（均为Arch）上也遇到了这个问题。 它通常会卡住超级/元键，但偶尔还会有其他修饰符（shift或ctrl）。 如果遇到问题（在本例中为例），如果重新启动屏障服务器，然后切换回客户端计算机，则一切正常。 如果我立即切换回主机，然后又切换回客户端，则Shift键会再次卡住。 修饰符也“停留”在客户端计算机的物理键盘上。 解决此问题的典型方法是让我重新启动客户端计算机。

关于如何帮助调试的任何建议将不胜感激，因为它使我感到非常疯狂。 我能够通过SSH进入客户端计算机。 我试过DISPLAY=:0 xset -q和DISPLAY=:0 xev进行调试，并且一切似乎都很正常（没有固定的修饰符与xset一起显示，并且在客户端上（通过barrierc或直接）按下了“正确”键。

使用屏障2.2.0和Synergy 1.10.1时存在此问题。

我几乎每天也都会收到此消息。 我在客户端和服务器上都运行Arch Linux（最近更新）。 该问题似乎主要影响客户端，即使在消除客户端计算机上的障碍后，该问题也像乔什一样继续存在。

要解决此问题，我必须注销（登录到我的TTY），重新登录并重新启动X。

我认为这对于Windows客户端也是一个问题，几个不同的修饰键可能会卡住。 如果有人可以可靠地复制它，那将很有帮助。

对我来说，它通常是Alt键。 我已配置好环境，以便使用Alt来移动和调整窗口大小（Alt +拖动）。 当我将窗口按住Alt键并拖动到屏幕边缘（通常允许鼠标移回主机的边缘）时，可能会触发该事件。 当我四处移动窗口时，我会保持警惕，看看是否与它有关（当鼠标在设备之间移动时，将按住修饰符）。

我有一个使用ubuntu服务器和Windows客户端卡住的元密钥。 首先，meta键仅适用于ubuntu，然后均不适用。

我们是否可以进行调试或提供日志以帮助解决此问题？ 在这一点上，我正在考虑切换到其他方法，因为仅为了使键盘每天工作而不得不关闭整个X窗口会话是不可持续的，而且问题似乎越来越严重。

如果有什么我可以提供的，此问题现在每天可靠地发生一次，因此我可以非常快速且重复地提供数据。

@DarwinSurvivor-我发现唯一可以“重置”（不留下X）的东西是以下内容……而且它并不理想（完全）：

#!/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

我现在以某种方式影响了非修饰符。

例如，我使用cVim，因此“ x”等效于“ Ctrl + F4”并关闭当前选项卡。 我的x键卡住了，这意味着当我切换到Chrome窗口时，它会迅速关闭我的所有标签，直到整个窗口消失。

我的超级钥匙有时会卡住。 正如DarwinSurvivor提到的那样，其他x之类的键也可能卡住，尽管这些键在我的计算机上等待一两秒钟后总是正确的。 我认为这是由（wi-fi）延迟引起的，因为我的光标也冻结了，而客户端混出了“ xxxxxxxxx”然后停止了。 但是，在重新启动X /重新启动之外，超级密钥问题似乎几乎是永久性的。

伺服器：Windows 10
客户端：Linux Mint 19.1 Cinnamon

我也可以使用ALT键。

该行为变为逆。 当我按下主机上的Alt键时，客户端的行为就像未按下一样。 它已经发生了两次。 我不确定是什么第一次修复了它。

伺服器：Windows 10
客户端：macOS High Sierra 10.13.6

*更新：
当ALT键卡住时，我可以按CONTROL键来解决它。

我在MacOS主机和Linux Mint客户端上遇到了相同的问题（卡住了超级键，有时是Ctrl键）。

尽管我观察到在使用带耳机的Skype或Google Hangouts时经常会发生这种情况，但没有已知原因，这种情况会间歇性地发生。 要解决有时重新启动X会有帮助，有时需要完全关闭/重新引导。 setxkbmap / xdotool似乎没有重置。

伺服器：macOS High Sierra 10.13.6
客户端：Linux Mint 18.3
网络：LAN连接到同一交换机，同一子网（无Wifi）
屏障2.3.2-发布-210c2b70

屏障中的什么会导致元键在客户端中被“按下”？ 我想可能有些天真，一定有一些事件导致状态改变，然后阻止状态重置。

Shift键未从客户端释放的相同问题。 我将重命名标题，因为它似乎不仅会影响超级键，而且还会影响更多的修饰符。

操作系统
服务器：Ubuntu 18.04（内核4.15.0-99-通用）
客户端：Ubuntu 18.04（内核5.3.0-51-通用）

屏障版本
伺服器：barrierc 2.3.2-13-g9080ce45
客户端：障碍物2.3.2-13-g9080ce45

在Synergy中发现了类似的问题https://github.com/symless/synergy-core/issues/6459

进行了小小的更新以使其清楚，每次按下Shift键都会发生未释放键，因此不太可能是由网络问题引起的。

服务器：屏障2.3.2-snapshot-210c2b70（Windows 10 1909）
客户端：屏障2.3.2-RELEASE-00000000（最新的Arch Linux，Xorg上的Mate 1.24）

同样，CTRL客户端卡在客户端上，在客户端上调用服务器（Windows）（Lock | SwitchUser | Sign Out | Task Manager）菜单时按CTRL-ALT-DEL，然后按ESC返回桌面，将客户端上的CTRL取消卡住几秒钟（最多20秒），然后再次卡住。

客户端和服务器上Debug2级别的日志都没有显示任何有用的信息，仅显示“进入/离开屏幕”消息。

错误使客户端几乎无法使用，因为由于ctrl的参与，它会将简单的击键解释为命令。

我也遇到了这个问题，客户端的ctrl和alt键都卡住了。
客户端和服务器均为Ubuntu，均为版本2.3.2-snapshot-9080ce45。

Debian 2.1.2 + dfsg-1
除非我仍然按下Shift键，否则在客户端上按Shift键将停止其他键的工作。 例如，输入L后，我只能输入其他大写字母。
将指针移回到服务器，然后再移回客户端，将其重置。

我的两台带有屏障2.3.3的Linux Mint（20和19）计算机之间经常发生。

原来右移键被卡住，标为SHIFT_R。
只需按下/释放键即可解决此问题。

可以通过以下方式检测卡住的键： xev | grep 'keycode .* (.*)'

除了我之前的评论外，在Linux客户端上，以下结合以下任何一种活动经常会发生这种情况：

• 快速窗口切换（例如alt-tab，按快速顺序按下，即alt-tab / alt-tab / alt而非alt-tab-tab-tab）。 这是断断续续的
• 使用音频或视频聊天应用（例如Zoom，Skype，环聊）。 在7/10个案例中这是可以预见的
• 通过wifi（而不是以太网）连接到网络
• 从wifi连接切换到以太网。 在8/10个案例中完全可以预测。

一旦有了按键（对我来说就是Ctrl键），其他症状就会在几秒钟到几分钟后开始出现，例如无法在新的终端窗口中键入随机字符，完全没有大写字母或根本没有键盘输入。 通常情况会变得更糟，唯一的解决方案是重新启动。

请注意，有时在没有任何这些活动的情况下也会发生这种情况，但很少发生。

客户：
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
屏障2.3.2-snapshot-210cb270
建立日期：2020年6月5日星期五

服务器：
Darwin 17.7.0 Darwin Kernel版本17.7.0：PDT 2020年5月27日星期三17:00:02； 根目录：xnu 4570.71.80.1〜1 / RELEASE_X86_64 x86_64
壁垒：2.3.2-发布-210cb270
建立日期：2019年10月3日

网络：以太网，1GB，相同的子网，有时甚至是wifi（屏障和客户端在同一路由器上，但​​是服务器通过以太网连接，客户端通过wifi连接）

更新

2020年8月26日-添加了wifi连接以增加频率
2020年8月28日-将wifi添加到以太网交换机中，成为频率的贡献者

今天遇到这个问题，我想我可以定期重现它。 尝试缩小确切步骤。

到目前为止，我的情况是：

1. 分配快捷方式以在客户端上启动屏障（我使用了CTRL-ALT-SHIFT-F9）
2. 在辅助键盘直接连接到客户端的情况下，使用快捷方式启动屏障（请注意，此键盘之前未运行）
3. 在主键盘连接到服务器的情况下，将屏幕切换到客户端（使用屏障快捷键CTRL-ALT-SHIFT-F12）
4. 按服务器键盘上的任何修改键（实际上不是必需的，但是会导致xkbwatch更新）

我发现，至少在某一点上，我在Linux客户端上运行了多个屏障进程（不是barrierc，而是barrier）。 我将重新启动所有内容，看看是否可以缩小一组步骤来清楚地再现问题。

好吧，我做了更多测试可靠地重现该问题：

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)

如果仔细阅读此内容，您会发现我能够恢复一次，但是第二次却没有恢复。

奇怪的是，似乎是由ALT键触发了它，尽管在这种尝试中，CTRL和SHIFT键是被卡住的。 我还发现使用xdotool可以重置修饰符，但是在使用下面的命令行（从上面的@joshskidmore复制）之前，我很难清除ALT（这似乎可以完成工作）（请注意，我必须通过SSH登录以运行此命令，因为卡住的修饰符使得无法直接在ubuntu计算机上运行命令）：

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！

还要注意，这次，在Linux客户端上从未检测到重复的屏障过程。

另一个数据点：使用SSH登录到Linux计算机并启动屏障，该问题不会发生。

嗯，还有另一个数据点：使用SSH登录到Linux计算机并启动屏障，同时按住辅助USB键盘（直接连接到Linux计算机）上的CTRL-ALT-SHIFT，确实会重现此问题。

我现在可以可靠地重现该问题：

1. linux客户端（笔记本电脑），macos服务器-客户端已成功连接到服务器（LAN网络）。 在任何时间都可以正常工作
2. 热拔插笔记本电脑，随时随地。 在某些时候打开wifi并直接在内置键盘和鼠标上工作（也就是说，无法连接到屏障服务器，网络不同）
3. 再次插回扩展坞，wifi仍然打开，障碍重新连接到服务器
4. 几次击键和鼠标单击，奇怪的事情开始发生。 Ctrl键被卡住。 键入会随意关闭或打开窗口（可能是Ctrl + Ctrl组合键），即使单击鼠标也无法达到预期的效果（例如，无法在Chrome中关闭窗口或打开新标签页）。

仅重启即可解决问题。

注意：如果屏障未运行，则不会发生这种情况。 我得出结论，这不是Linux /硬件问题。

客户：
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
屏障2.3.2-snapshot-210cb270
建立日期：2020年6月5日星期五

服务器：
Darwin 17.7.0 Darwin Kernel版本17.7.0：PDT 2020年5月27日星期三17:00:02； 根目录：xnu 4570.71.80.1〜1 / RELEASE_X86_64 x86_64
壁垒：2.3.2-发布-210cb270
建立日期：2019年10月3日

当它发生在我身上时，我并没有插拔任何东西。 这两台笔记本电脑始终都处于WiFi状态（除非有一些我不知道的静默断开连接和重新连接，但是我没有理由怀疑是否有静默断开连接。

我和你有同样的问题，使障碍无法使用...：'（