Barrier: супер-клавиша (клавиша Windows) застревает в "нажатой" на клиенте

У меня также есть эта проблема с linux server -> linux client (оба Arch). Часто это застрявшая супер / мета-клавиша, но иногда и другие модификаторы (shift или ctrl). Если у меня возникнет проблема (скажем, смена для этого примера), если я перезапущу барьерный сервер, переключусь обратно на клиентскую машину, все в порядке. Если я немедленно переключаюсь обратно на хост, а затем обратно на клиент, клавиша Shift снова застревает. Модификатор также остается «застрявшим» на физической клавиатуре клиентского компьютера. Типичный способ решить эту проблему - просто перезагрузить клиентский компьютер.

Любые советы о том, как я могу помочь отладить это, были бы оценены, так как это сводит меня с ума. Я могу подключиться к клиентской машине по SSH. Я пробовал DISPLAY=:0 xset -q и DISPLAY=:0 xev для отладки, и все кажется нормальным (никакие удерживаемые модификаторы не отображаются с xset, а «правильные» клавиши нажимаются (через barrierc или напрямую) на клиенте.

Эта проблема существует при использовании Barrier 2.2.0, а также Synergy 1.10.1.

Я тоже получаю это практически ежедневно. Я использую Arch Linux (недавно обновленный) как на клиенте, так и на сервере. Проблема в первую очередь, по-видимому, затрагивает клиента и, как и Джош, продолжается даже после уничтожения барьера на клиентской машине.

Чтобы решить эту проблему, мне нужно выйти (в свой TTY), снова войти в систему и перезапустить X.

Я думаю, что это проблема и для клиентов Windows, и несколько разных клавиш-модификаторов могут застрять. Если кто-то может воспроизвести его достоверно, это будет полезно.

Для меня это, как правило, клавиша Alt. Моя среда настроена так, что Alt используется для перемещения и изменения размера окон (Alt + перетаскивание). Возможно, он срабатывает, когда я перетаскиваю окно к краю экрана (край, который обычно позволяет моей мыши вернуться к главному компьютеру). Я буду следить, когда перемещаю окна, и смотрю, связано ли это с этим (модификатор удерживается, когда мышь перемещается между устройствами).

У меня застрял мета-ключ с использованием сервера ubuntu и клиента Windows. Сначала мета-ключ работает только для ubuntu, а затем не работает ни для одного другого.

Можем ли мы выполнить какую-либо отладку или предоставить журналы, которые могут помочь решить эту проблему? На данный момент я подумываю о переключении на что-то другое, потому что необходимость закрывать весь сеанс X-window только для того, чтобы моя клавиатура работала каждый день, нецелесообразна, и проблема, похоже, усугубляется.

Если есть что-то, что я могу предоставить, эта проблема теперь надежно возникает один раз в день, поэтому я могу предоставлять данные очень быстро и многократно.

@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, он закрывает все мои вкладки, пока все окно не исчезнет.

Мой супер-ключ иногда вот так застревает. Другие ключи, такие как x, также могут застрять, как упоминал DarwinSurvivor, хотя эти ключи всегда сразу же появляются через секунду или две на моей машине. Я предположил, что это было вызвано задержкой (Wi-Fi), так как мой курсор также зависает, когда клиент выдает «xxxxxxxxx», а затем останавливается. Проблема с супер-ключом кажется почти постоянной, если не считать перезапуска X / перезагрузки.

Сервер: Windows 10
Клиент: Linux Mint 19.1 Cinnamon

Я получаю то же самое с клавишей ALT.

Поведение становится обратным. Когда я нажимаю клавишу Alt на хосте, клиент ведет себя так, как будто он не нажат. Это случилось уже дважды. Я не уверен, что это исправило в первый раз.

Сервер: Windows 10
Клиент: macOS High Sierra 10.13.6

*Обновить:
Когда клавиша ALT застревает, я могу нажать клавишу CONTROL, чтобы решить эту проблему.

Я испытываю то же самое (залипает супер-клавиша, иногда клавиша Ctrl) с хостом MacOS и клиентом Linux Mint.

Это происходит периодически без известной причины, хотя я заметил, что это часто происходит при использовании Skype или Google Hangout с гарнитурой. Иногда помогает перезапуск X, иногда требуется полное выключение / перезагрузка. setxkbmap / xdotool не сбрасывается.

Сервер: macOS High Sierra 10.13.6
Клиент: Linux Mint 18.3
Сеть: подключение по локальной сети к тому же коммутатору, в той же подсети (без Wi-Fi)
Барьер 2.3.2-Release-210c2b70

Что в Barrier может вызывать «нажатие» мета-клавиш в клиенте? Должно быть какое-то событие, которое вызывает изменение состояния и затем препятствует его сбросу, я предполагаю, возможно, наивно.

Та же проблема с клавишей Shift, не отпущенной от клиента. Я бы переименовал заголовок, так как он, кажется, влияет на большее количество модификаторов, чем просто супер-ключ.

Операционные системы
Сервер: Ubuntu 18.04 (общее ядро ​​4.15.0-99)
Клиент: Ubuntu 18.04 (ядро 5.3.0-51-generic)

Барьерная версия
Сервер: barrierc 2.3.2-13-g9080ce45
Клиент: барьеры 2.3.2-13-g9080ce45

Обнаружена аналогичная проблема в Synergy https://github.com/symless/synergy-core/issues/6459

Небольшое обновление, чтобы прояснить: невыпущенная клавиша происходит каждый раз, когда я нажимаю клавишу Shift, поэтому маловероятно, что это связано с проблемой сети.

Сервер: барьер 2.3.2-снимок-210c2b70 (Windows 10 1909)
Клиент: барьер 2.3.2-RELEASE-00000000 (последняя версия Arch Linux, Mate 1.24 поверх Xorg)

То же самое, клиент CTRL застрял на клиенте, нажав CTRL-ALT-DEL, в то время как клиент вызывает меню сервера (Windows) (Lock | SwitchUser | Выход | Диспетчер задач), затем ESC, чтобы вернуться на рабочий стол, отключает CTRL на клиенте для несколько секунд (максимум 20 секунд), затем он снова застревает самостоятельно.

Журналы на уровне Debug2 как на клиенте, так и на сервере не показывают ничего полезного, только сообщения «вход / выход из экрана».

Ошибка делает клиент непригодным для использования, так как он интерпретирует простые нажатия клавиш как команды из-за задействования ctrl.

Я тоже испытываю это, когда клавиши ctrl и alt на клиенте застревают.
Клиент и сервер - это Ubuntu, обе версии 2.3.2-snapshot-9080ce45.

Debian 2.1.2 + dfsg-1
Клавиша Shift, нажатая на клиенте, останавливает работу других клавиш, если я все еще не нажимаю клавишу Shift. например, после ввода L я могу вводить только другие заглавные буквы.
Перемещение указателя обратно на сервер, а затем обратно на клиент, сбрасывает его.

Регулярно происходит между двумя моими компьютерами Linux Mint (20 и 19) с Barrier 2.3.3.

Оказывается, правая клавиша Shift застревает, помеченная SHIFT_R.
Простое нажатие / отпускание клавиши решает проблему.

Застрявшие ключи можно обнаружить следующим образом: xev | grep 'keycode .* (.*)'

В дополнение к моему предыдущему комментарию , это часто происходит в связи с одним из следующих действий на клиенте Linux:

• быстрые переключатели окон (например, alt-tab, нажатие в быстрой последовательности, например alt-tab / alt-tab / alt tab в отличие от alt-tab-tab-tab). это периодически
• используя приложения для аудио- или видеочата, такие как Zoom, Skype, Hangout. это вполне предсказуемо в 7 из 10 случаев
• подключение к сети через Wi-Fi (вместо Ethernet)
• переключение с Wi-Fi на Ethernet. вполне предсказуемо в 8/10 случаях.

Как только клавиша становится доступной (для меня это клавиша Ctrl), через несколько секунд или минут начинают проявляться другие симптомы, такие как невозможность вводить случайные символы в новом окне терминала, отсутствие заглавных букв или отсутствие ввода с клавиатуры. Обычно ситуация ухудшается, и единственное решение - перезагрузка.

Обратите внимание, что это также иногда происходит без каких-либо из этих действий, но реже.

Клиент:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Пт, 12 июня 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Барьер 2.3.2-снимок-210cb270
Дата сборки: пятница, 5 июня 2020 г.

Сервер:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: среда, 27 мая, 17:00:02 PDT 2020; корень: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Барьер: 2.3.2-Release-210cb270
Дата сборки: 3 октября 2019 г.

Сеть: Ethernet, 1 ГБ, та же подсеть, иногда Wi-Fi (барьер и клиент находятся на одном маршрутизаторе, однако сервер подключен через Ethernet, клиент через Wi-Fi)

Обновлено

26 августа 2020 г. - добавлено подключение к Wi-Fi в качестве источника частоты
28 августа 2020 г. - добавлен Wi-Fi к коммутатору Ethernet в качестве источника частоты

Столкнувшись с этой проблемой сегодня, я думаю, что могу воспроизводить ее достаточно регулярно. Пытаемся сузить точные шаги.

На данный момент у меня есть следующее:

1. Назначьте ярлык для запуска барьера на клиенте (я использовал CTRL-ALT-SHIFT-F9)
2. Запустите барьер с помощью ярлыка с дополнительной клавиатурой, напрямую подключенной к клиенту (обратите внимание, что до этого он не работал)
3. Переключить экран на клиент с основной клавиатурой, подключенной к серверу (с помощью ярлыка барьера, CTRL-ALT-SHIFT-F12)
4. Нажмите любую клавишу-модификатор на клавиатуре сервера (на самом деле не обязательно, но вызывает обновление xkbwatch)

Я обнаружил, что, по крайней мере, в какой-то момент у меня было запущено несколько процессов барьера (не barrierc, а барьер) на клиенте Linux. Я собираюсь перезапустить все заново и посмотреть, смогу ли я сузить набор шагов, которые точно воспроизводят проблему.

Хорошо, я провел еще несколько тестов,достоверно воспроизводит проблему:

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 для сброса модификаторов работает, но у меня были проблемы с очисткой ALT, пока я не использовал следующую командную строку, скопированную из

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-машину и запуск барьера, ПРИ Удерживании CTRL-ALT-SHIFT на вторичной USB-клавиатуре (напрямую подключенной к Linux-машине) ДЕЙСТВИТЕЛЬНО воспроизводит проблему.

Теперь я могу достоверно воспроизвести проблему:

1. клиент linux (ноутбук), сервер macos - клиент успешно подключен к серверу (сеть LAN). работает без проблем любое количество времени
2. ноутбук с возможностью горячего отключения в пути. в какой-то момент включите Wi-Fi и работайте напрямую со встроенной клавиатурой и мышью (то есть подключение к барьерному серверу невозможно, другая сеть)
3. снова подключите к док-станции, Wi-Fi все еще включен, барьер подключается обратно к серверу нормально
4. несколько нажатий клавиш и щелчков мыши начинают происходить странные вещи. Клавиша ctrl застряла. ввод закрывает или открывает окна по желанию (возможно, комбинация клавиш ctrl +), даже щелчки мышью не приводят к ожидаемому результату (например, невозможно закрыть окно или открыть новую вкладку в Chrome).

Только перезагрузка решает проблему.

Примечание: этого не происходит, когда шлагбаум не работает. Я пришел к выводу, что это не проблема Linux / оборудования.

Клиент:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP Пт, 12 июня 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Барьер 2.3.2-снимок-210cb270
Дата сборки: пятница, 5 июня 2020 г.

Сервер:
Darwin 17.7.0 Darwin Kernel Version 17.7.0: среда, 27 мая, 17:00:02 PDT 2020; корень: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Барьер: 2.3.2-Release-210cb270
Дата сборки: 3 октября 2019 г.

Когда это случилось со мной, я ничего не подключал и не отключал. Оба ноутбука оставались подключенными к Wi-Fi повсюду (если не было каких-то бесшумных отключений и повторных подключений, о которых я не знаю, но у меня нет причин подозревать какие-либо тихие отключения.

У меня та же проблема, что и у вас, что делает барьер непригодным для использования ...: '(