Barrier: 수퍼 키 (Windows 키)가 클라이언트에서 "눌림"상태로 멈춤

또한 Linux 서버-> Linux 클라이언트 (둘 다 Arch) 에서도이 문제가 있습니다. 종종 고정 된 수퍼 / 메타 키이지만 때때로 다른 수정 자 (shift 또는 ctrl)입니다. 문제가 발생하면 (이 예에서는 시프트라고합시다) 배리어 서버를 다시 시작하고 클라이언트 시스템으로 다시 전환하면 정상입니다. 즉시 호스트로 다시 전환 한 다음 클라이언트로 다시 전환하면 Shift 키가 다시 멈 춥니 다. 수정자는 클라이언트 시스템의 물리적 키보드에서도 "고정"상태로 유지됩니다. 이 문제를 해결하는 일반적인 방법은 클라이언트 시스템을 재부팅하는 것입니다.

내가 이것을 디버깅하는 데 도움이 될 수있는 방법에 대한 조언은 나를 절대적으로 미치게 만들기 때문에 감사 할 것입니다. 클라이언트 컴퓨터에 SSH를 사용할 수 있습니다. 디버그를 위해 DISPLAY=:0 xset -q 및 DISPLAY=:0 xev 을 (를) 시도했는데 모든 것이 정상인 것처럼 보입니다 (xset에 고정 된 수정자가 표시되지 않고 "올바른"키가 클라이언트에서 (barrierc를 통해 또는 직접) 눌러지고 있음).

이 문제는 Barrier 2.2.0과 Synergy 1.10.1을 사용하여 발생합니다.

나는 이것을 거의 매일 받고있다. 클라이언트와 서버 모두에서 Arch Linux (최근 업데이트 됨)를 실행하고 있습니다. 이 문제는 주로 클라이언트에 영향을 미치는 것으로 보이며 Josh와 마찬가지로 클라이언트 시스템의 장벽을 없앤 후에도 계속됩니다.

문제를 해결하려면 로그 아웃 (TTY로)하고 다시 로그인 한 다음 X를 다시 시작해야합니다.

나는 이것이 Windows 클라이언트에서도 문제이며 여러 가지 수정 키가 멈출 수 있다고 생각합니다. 누구나 안정적으로 재현 할 수 있다면 도움이 될 것입니다.

저에게는 Alt 키인 경향이 있습니다. Alt를 사용하여 창을 이동하고 크기를 조정하도록 환경을 구성했습니다 (Alt + 드래그). 창을 화면 가장자리 (보통 내 마우스가 호스트 컴퓨터로 다시 이동할 수 있도록 허용하는 가장자리)로 Alt 키를 누른 상태에서 드래그하면 트리거 될 수 있습니다. 나는 창문을 움직일 때 주시하고 그것이 그것과 관련이 있는지 확인 할 것입니다 (마우스가 장치 사이를 이동할 때 수정자가 잡혀 있음).

우분투 서버와 Windows 클라이언트를 사용하여 메타 키가 붙어 있습니다. 처음에는 메타 키가 우분투에서만 작동하고 어느 쪽에서도 작동하지 않습니다.

이 문제를 해결하는 데 도움이 될 수있는 디버깅이나 제공 할 수있는 로그가 있습니까? 이 시점에서 나는 키보드를 매일 작동시키기 위해 전체 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 키가 멈췄습니다. 즉, 크롬 창으로 전환하면 전체 창이 사라질 때까지 빠른 파일러가 모든 탭을 닫습니다.

내 슈퍼 키가 가끔 이렇게 멈춰요. DarwinSurvivor가 언급했듯이 x와 같은 다른 키도 멈출 수 있습니다. 클라이언트가 'xxxxxxxxx'를 매시 아웃 한 다음 중지하는 동안 커서도 동결되기 때문에 (wi-fi) 지연으로 인해 발생했다고 가정했습니다. 슈퍼 키 문제는 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 Hangout을 사용할 때 자주 발생하는 것으로 나타났습니다. X를 다시 시작하면 문제를 해결하기 위해 때로는 전체 종료 / 재부팅이 필요합니다. setxkbmap / xdotool이 재설정되지 않는 것 같습니다.

서버 : macOS High Sierra 10.13.6
클라이언트 : Linux Mint 18.3
네트워크 : 동일한 스위치에 LAN 연결, 동일한 서브넷 (WiFi 없음)
배리어 2.3.2- 릴리스 -210c2b70

Barrier의 무엇으로 인해 클라이언트에서 메타 키가 "눌려"지게됩니까? 상태 변경을 유발 한 다음 재설정되지 않도록하는 이벤트가 있어야합니다. 아마도 순진하다고 생각합니다.

클라이언트에서 해제되지 않은 Shift 키와 동일한 문제. 수퍼 키보다 더 많은 수정 자에 영향을 미치는 것처럼 보이기 때문에 제목의 이름을 바꿉니다.

운영체제
서버 : Ubuntu 18.04 (Kernel 4.15.0-99-generic)
클라이언트 : Ubuntu 18.04 (Kernel 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-snapshot-210c2b70 (Windows 10 1909)
클라이언트 : 장벽 2.3.2-RELEASE-00000000 (Arch Linux 최신 버전, Mate 1.24 over Xorg)

마찬가지로, 클라이언트에서 CTRL-ALT-DEL을 누르면 클라이언트에서 서버 (Windows) (잠금 | SwitchUser | 로그 아웃 | 작업 관리자) 메뉴를 호출 한 다음 ESC를 눌러 데스크톱으로 돌아갑니다. 몇 초 (최대 20 초), 그런 다음 자체적으로 다시 멈 춥니 다.

클라이언트와 서버 모두에서 Debug2 수준의 로그는 "화면 진입 / 나가기"메시지 만 표시하고 유용하지 않습니다.

버그는 ctrl 관련으로 인해 간단한 키 입력을 명령으로 해석하므로 클라이언트를 사용할 수 없게 만듭니다.

클라이언트의 ctrl 및 alt 키가 모두 멈춰있는 상태에서도이 문제가 발생합니다.
클라이언트와 서버는 둘 다 Ubuntu이며 버전 2.3.2-snapshot-9080ce45입니다.

데비안 2.1.2 + dfsg-1
클라이언트에서 Shift 키를 누르면 여전히 Shift 키를 누르지 않는 한 다른 키가 작동하지 않습니다. 예를 들어 L을 입력 한 후 다른 대문자 만 입력 할 수 있습니다.
포인터를 서버로 다시 이동 한 다음 클라이언트로 다시 이동하면 다시 설정됩니다.

Barrier 2.3.3이 설치된 두 Linux Mint (20 및 19) 컴퓨터간에 정기적으로 발생합니다.

SHIFT_R이라는 레이블이 붙은 오른쪽 시프트 키가 멈춰 있습니다.
키를 간단히 눌렀다가 놓으면 문제가 해결됩니다.

고정 된 키는 다음 방법으로 감지 할 수 있습니다. xev | grep 'keycode .* (.*)'

이전 의견 외에도 Linux 클라이언트에서 다음 활동 중 하나와 관련하여 자주 발생합니다.

• 빠른 창 전환 (예 : alt-tab, 빠른 순서로 눌림, 즉 alt-tab-tab-tab과 반대되는 alt-tab / alt-tab / alt 탭). 이것은 간헐적이다
• Zoom, Skype, Hangout과 같은 음성 또는 영상 채팅 앱을 사용합니다. 이것은 7/10 사례에서 꽤 예측 가능합니다.
• Wi-Fi를 통해 네트워크에 연결됨 (이더넷 대신)
• Wi-Fi 연결에서 이더넷으로 전환. 8/10 사례에서 꽤 예측 가능합니다.

키가 재고 (저에게는 Ctrl 키)가되면 새 터미널 창에서 임의의 문자를 입력 할 수 없거나 대문자가 없거나 키보드 입력이 전혀없는 것과 같은 다른 증상이 몇 초에서 몇 분 후에 나타나기 시작합니다. 일반적으로 상황이 악화되고 유일한 해결책은 재부팅하는 것입니다.

때로는 이러한 활동 없이도 발생하지만 드물게 발생합니다.

고객:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP 금요일 6 월 12 일 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
배리어 2.3.2- 스냅 샷 -210cb270
빌드 날짜 : 2020 년 6 월 5 일 금요일

섬기는 사람:
Darwin 17.7.0 Darwin Kernel 버전 17.7.0 : Wed May 27 17:00:02 PDT 2020; 루트 : xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
장벽 : 2.3.2-Release-210cb270
빌드 날짜 : 2019 년 10 월 3 일

네트워크 : 이더넷, 1GB, 동일한 서브넷, 때때로 wifi (배리어와 클라이언트는 동일한 라우터에 있지만 서버는 이더넷을 통해 연결되고 클라이언트는 wifi를 통해 연결됨)

업데이트 됨

2020 년 8 월 26 일-주파수 기여자로 Wi-Fi 연결 추가
2020 년 8 월 28 일-주파수 기여자로 이더넷 스위치에 Wi-Fi 추가

오늘이 문제에 부딪히면 상당히 정기적으로 재현 할 수 있다고 생각합니다. 정확한 단계를 좁히려 고합니다.

지금까지 내가 가진 것은 다음과 같습니다.

1. 클라이언트에서 장벽을 시작하는 바로 가기 지정 (CTRL-ALT-SHIFT-F9 사용)
2. 클라이언트에 직접 연결된 보조 키보드로 바로 가기를 사용하여 장벽 시작 (이전에는 실행되지 않았 음)
3. 기본 키보드가 서버에 연결된 클라이언트로 화면 전환 (배리어 단축키 CTRL-ALT-SHIFT-F12 사용)
4. 서버 키보드에서 임의의 수정 자 키를 누르십시오 (실제로는 필요하지 않지만 xkbwatch가 업데이트 됨).

적어도 한 지점에서 Linux 클라이언트에서 여러 개의 장벽 프로세스 (barrierc가 아니라 장벽)가 실행되고 있음을 발견했습니다. 모든 것을 새로 다시 시작하고 문제를 깔끔하게 재현하는 일련의 단계를 좁힐 수 있는지 확인하겠습니다.

좋아, 좀 더 테스트를했는데문제를 안정적으로 재현합니다.

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)

자세히 읽어 보면 한 번은 회복 할 수 있었지만 두 번째로는 회복되지 않았 음을 알 수 있습니다.

이상한 점은이 시도에서 CTRL 및 SHIFT 키가 멈춘 키 였음에도 불구하고 트리거하는 것처럼 보이는 ALT 키라는 것입니다. 또한 xdotool 를 사용하여 수정자를 재설정하는 것이 작동한다는 것을 발견했지만 위의 @joshskidmore 에서 복사 한 다음 명령 줄을 사용할 때까지 ALT를 지우는 데 문제가있었습니다. 고정 된 수정 자로 인해 우분투 머신에서 직접 명령을 실행할 수 없으므로 SSH를 통해 로그인하여 실행하십시오.)

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. 이동 중에도 핫-플러그 노트북. 어느 시점에서 Wi-Fi를 켜고 내장 키보드 및 마우스에서 직접 작업합니다 (즉, 배리어 서버에 연결할 수 없으며 다른 네트워크).
3. 도킹 스테이션에 다시 연결하고 Wi-Fi는 계속 켜져 있고 장벽이 서버에 다시 연결됩니다.
4. 몇 번의 키 입력과 마우스 클릭, 이상한 일이 일어나기 시작합니다. Ctrl 키가 멈췄습니다. 타이핑을하면 마음대로 창을 닫거나 열 수 있습니다 (아마도 Ctrl + 키 조합 일 가능성이 높음). 마우스 클릭으로도 예상 한 결과를 얻지 못합니다 (예 : 창을 닫거나 Chrome에서 새 탭을 열 수 없음).

재부팅 만하면 문제가 해결됩니다.

참고 : 배리어가 작동하지 않을 때는 발생하지 않습니다. Linux / 하드웨어 문제가 아니라는 결론을 내립니다.

고객:
Linux 4.15.0-107-generic # 108 ~ 16.04.1-Ubuntu SMP 금요일 6 월 12 일 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
배리어 2.3.2- 스냅 샷 -210cb270
빌드 날짜 : 2020 년 6 월 5 일 금요일

섬기는 사람:
Darwin 17.7.0 Darwin Kernel 버전 17.7.0 : Wed May 27 17:00:02 PDT 2020; 루트 : xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
장벽 : 2.3.2-Release-210cb270
빌드 날짜 : 2019 년 10 월 3 일

나에게 그런 일이 일어 났을 때 나는 아무것도 꽂거나 뽑지 않았다. 두 노트북 모두 WiFi에 머물 렀습니다.

나는 장벽을 사용할 수 없게 만드는 당신과 같은 문제가 있습니다 ... : '(