Barrier: tombol super (tombol windows) macet di "ditekan" pada klien

Saya juga memiliki masalah ini dengan server linux -> klien linux (keduanya Arch). Ini seringkali merupakan kunci super / meta yang macet, tetapi terkadang pengubah lain (shift atau ctrl). Jika saya mengalami masalah (katakanlah pergeserannya untuk contoh ini), jika saya me-restart server penghalang, beralih kembali ke mesin klien, semuanya normal. Jika saya segera beralih kembali ke host, lalu kembali ke klien, tombol shift macet lagi. Pengubah juga tetap "tertahan" di keyboard fisik mesin klien. Cara khas untuk mengatasinya adalah dengan me-reboot mesin klien.

Setiap saran tentang bagaimana saya dapat membantu debug ini akan dihargai karena itu membuat saya benar-benar gila. Saya bisa SSH ke mesin klien. Saya telah mencoba DISPLAY=:0 xset -q dan DISPLAY=:0 xev untuk men-debug dan semuanya tampak normal (tidak ada pengubah yang ditahan yang ditampilkan dengan xset dan tombol "benar" sedang ditekan (melalui penghalang atau secara langsung) pada klien.

Masalah ini ada menggunakan Barrier 2.2.0 serta Synergy 1.10.1.

Saya mendapatkan ini hampir setiap hari juga. Saya menjalankan Arch Linux (baru-baru ini diperbarui) pada klien dan server. Masalah utamanya tampaknya memengaruhi klien, dan seperti Josh, berlanjut bahkan setelah mematikan penghalang pada mesin klien.

Untuk memperbaiki masalah ini, saya harus keluar (ke TTY saya), masuk kembali dan memulai ulang X.

Saya rasa ini juga menjadi masalah bagi klien Windows dan beberapa kunci pengubah yang berbeda dapat macet. Jika ada yang dapat mereproduksinya dengan andal, itu akan membantu.

Bagi saya, ini cenderung menjadi tombol Alt. Saya telah mengkonfigurasi lingkungan saya sehingga Alt digunakan untuk memindahkan dan mengubah ukuran jendela (Alt + drag). Mungkin saja itu dipicu ketika saya alt-drag jendela ke tepi layar (tepi yang biasanya memungkinkan mouse saya untuk kembali ke komputer host). Saya akan mengawasi saat saya memindahkan jendela dan melihat apakah itu ada hubungannya dengan itu (pengubah ditahan saat mouse bergerak antar perangkat).

Saya memiliki kunci meta yang macet menggunakan server ubuntu dan klien windows. Pada kunci meta pertama hanya berfungsi untuk ubuntu dan kemudian tidak berfungsi untuk keduanya.

Apakah ada debugging yang dapat kami lakukan atau log yang dapat kami sediakan yang dapat membantu menyelesaikan masalah ini? Pada titik ini, saya sedang mempertimbangkan untuk beralih ke sesuatu yang lain karena harus menutup seluruh sesi X-window saya hanya untuk membuat keyboard saya bekerja setiap hari tidak berkelanjutan dan masalahnya tampaknya semakin buruk.

Jika ada yang bisa saya berikan, masalah ini sekarang andal terjadi sekali sehari, jadi saya bisa memberikan data dengan sangat cepat dan berulang kali.

@DarwinSurvivor - Satu-satunya hal yang saya temukan untuk "mengatur ulang" ini (tanpa meninggalkan X) adalah sebagai berikut ... dan itu tidak ideal (sama sekali):

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

Saya sekarang telah mengalami ini mempengaruhi non-pengubah entah bagaimana.

Misalnya, saya menggunakan cVim, jadi "x" sama dengan "Ctrl + F4" dan menutup tab saat ini. Saya memiliki kunci x macet, yang berarti ketika saya beralih ke jendela chrome, fast-filer menutup semua tab saya sampai seluruh jendela menghilang.

Super-key saya terkadang macet seperti ini. Kunci lain seperti x juga bisa macet, seperti yang disebutkan DarwinSurvivor, meskipun kunci itu selalu benar sendiri setelah satu atau dua detik di mesin saya. Saya berasumsi bahwa itu disebabkan oleh kelambatan (wi-fi) karena kursor saya membeku juga sementara klien menghapus 'xxxxxxxxx' lalu berhenti. Masalah super-key tampaknya hampir permanen, di luar memulai ulang X / me-reboot.

Server: Windows 10
Klien: Linux Mint 19.1 Cinnamon

Saya mendapatkan yang sama dengan tombol ALT.

Perilaku menjadi terbalik. Ketika saya menekan tombol Alt pada host maka klien berperilaku seperti tidak ditekan. Itu sudah terjadi dua kali. Saya tidak yakin apa yang memperbaikinya pertama kali.

Server: Windows 10
Klien: macOS High Sierra 10.13.6

*memperbarui:
Saat tombol ALT macet, saya bisa menekan tombol CONTROL untuk menyelesaikannya.

Saya mengalami hal yang sama (tombol Super macet, terkadang tombol Ctrl) dengan host MacOS dan klien Linux Mint.

Ini terjadi sesekali tanpa penyebab yang diketahui, meskipun saya mengamati bahwa ini sering terjadi saat menggunakan Skype atau Google Hangout dengan head set. Untuk mengatasi terkadang restart X membantu, terkadang shutdown / reboot penuh diperlukan. setxkbmap / xdotool sepertinya tidak diatur ulang.

Server: macOS High Sierra 10.13.6
Klien: Linux Mint 18.3
Jaringan: Koneksi LAN ke sakelar yang sama, subnet yang sama (tanpa Wifi)
Penghalang 2.3.2-Release-210c2b70

Apa di Barrier yang akan menyebabkan kunci meta menjadi "ditekan" di klien? Pasti ada beberapa peristiwa yang menyebabkan perubahan status dan kemudian membuatnya tidak disetel ulang, saya kira mungkin secara naif.

Masalah yang sama dengan tombol Shift tidak dilepaskan dari klien. Saya akan mengganti nama judul karena tampaknya mempengaruhi lebih banyak pengubah daripada hanya kunci super.

Sistem operasi
Server: Ubuntu 18.04 (Kernel 4.15.0-99-generik)
Klien: Ubuntu 18.04 (Kernel 5.3.0-51-generic)

Versi Barrier
Server: barrierc 2.3.2-13-g9080ce45
Klien: hambatan 2.3.2-13-g9080ce45

Menemukan masalah serupa di Synergy https://github.com/symless/synergy-core/issues/6459

Pembaruan kecil untuk memperjelas, kunci yang belum dirilis terjadi setiap kali saya menekan tombol shift sehingga tidak mungkin disebabkan oleh masalah jaringan.

Server: penghalang 2.3.2-snapshot-210c2b70 (Windows 10 1909)
Klien: barrier 2.3.2-RELEASE-00000000 (Arch Linux up to date, Mate 1.24 di atas Xorg)

Sama, klien CTRL terjebak di klien, menekan CTRL-ALT-DEL saat klien memanggil menu Server (Windows) (Lock | SwitchUser | Keluar | Task Manager), lalu ESC untuk kembali ke desktop menghapus CTRL pada klien untuk a beberapa detik (paling banyak 20 detik), lalu macet lagi dengan sendirinya.

Log di tingkat Debug2 pada klien dan server tidak menunjukkan apa pun yang berguna, hanya pesan "layar masuk / keluar".

Bug membuat klien sangat tidak dapat digunakan, karena menafsirkan penekanan tombol sederhana sebagai perintah karena keterlibatan ctrl.

Saya mengalami ini juga, dengan tombol ctrl dan alt pada klien macet.
Client dan Server keduanya Ubuntu, keduanya versi 2.3.2-snapshot-9080ce45.

Debian 2.1.2 + dfsg-1
Tombol shift yang ditekan pada klien menghentikan tombol lain yang berfungsi kecuali saya masih menekan tombol shift. misal setelah mengetik L maka saya hanya bisa mengetikkan huruf kapital lainnya.
Memindahkan pointer kembali ke server kemudian kembali ke klien mengatur ulang itu.

Terjadi secara teratur antara dua komputer Linux Mint (20 dan 19) saya dengan Barrier 2.3.3.

Ternyata tombol shift kanan macet, berlabel SHIFT_R.
Pers / rilis sederhana dari tombol tersebut menyelesaikan masalah.

Kunci yang macet dapat dideteksi dengan cara ini: xev | grep 'keycode .* (.*)'

Selain komentar saya sebelumnya, ini sering terjadi sehubungan dengan salah satu aktivitas berikut, di klien Linux:

• saklar jendela cepat (misalnya alt-tab, ditekan dalam urutan cepat, yaitu alt-tab / alt-tab / alt tab sebagai lawan alt-tab-tab-tab). ini terputus-putus
• menggunakan aplikasi obrolan audio atau video seperti Zoom, Skype, Hangout. ini cukup dapat diprediksi, katakanlah 7/10 kasus
• sedang terhubung ke jaringan melalui wifi (bukan ethernet)
• beralih dari koneksi wifi ke ethernet. cukup dapat diprediksi dalam 8/10 kasus.

Setelah kunci mendapat stok (bagi saya itu adalah tombol Ctrl), gejala lain mulai muncul beberapa detik ke menit kemudian seperti tidak dapat mengetik karakter acak di jendela terminal baru, tidak ada huruf besar atau tidak ada input keyboard sama sekali. Biasanya situasinya semakin buruk dan satu-satunya solusi adalah reboot.

Perhatikan bahwa terkadang juga terjadi tanpa aktivitas ini, tetapi lebih jarang terjadi.

Klien:
Linux 4.15.0-107-generik # 108 ~ 16.04.1-Ubuntu SMP Jum 12 Jun 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Penghalang 2.3.2-snapshot-210cb270
Tanggal Dibangun: Jumat 5 Juni 2020

Server:
Darwin 17.7.0 Versi Kernel Darwin 17.7.0: Rabu 27 Mei 17:00:02 PDT 2020; root: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Penghalang: 2.3.2-Release-210cb270
Tanggal Dibangun: 3 Oktober 2019

Jaringan: Ethernet, 1GB, subnet yang sama, terkadang wifi (penghalang dan klien berada di router yang sama, namun server terhubung melalui ethernet, klien melalui wifi)

Diperbarui

26 Agustus 2020 - menambahkan koneksi wifi sebagai kontributor frekuensi
28 Agustus 2020 - menambahkan wifi ke ethernet switch sebagai kontributor frekuensi

Mengalami masalah ini hari ini, saya rasa saya dapat mereproduksinya secara teratur. Mencoba mempersempit langkah-langkah yang tepat.

Apa yang saya miliki sejauh ini adalah:

1. Tetapkan jalan pintas untuk memulai penghalang pada klien (saya menggunakan CTRL-ALT-SHIFT-F9)
2. Mulai penghalang menggunakan pintasan dengan keyboard sekunder langsung terhubung ke klien (perhatikan itu tidak berjalan sebelum ini)
3. Alihkan layar ke klien dengan keyboard utama terhubung ke server (menggunakan pintasan penghalang, CTRL-ALT-SHIFT-F12)
4. Tekan sembarang tombol pengubah pada keyboard server (sebenarnya tidak perlu, tetapi menyebabkan xkbwatch memperbarui)

Saya menemukan bahwa, setidaknya pada satu titik, saya menjalankan beberapa proses penghalang (bukan penghalang, tetapi penghalang), pada klien Linux. Saya akan memulai ulang semua yang baru dan melihat apakah saya dapat mempersempit serangkaian langkah yang mereproduksi masalah dengan bersih.

Oke, saya melakukan pengujian lagimereproduksi masalah dengan andal:

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)

Jika Anda membaca ini dengan saksama, Anda akan menemukan bahwa saya dapat memulihkan satu kali, tetapi untuk kedua kalinya, tidak pulih.

Yang aneh adalah bahwa tombol ALT-lah yang tampaknya memicunya, meskipun, dalam upaya ini, tombol CTRL dan SHIFT-lah yang macet. Saya juga menemukan bahwa menggunakan xdotool untuk mengatur ulang pengubah berfungsi, tetapi saya mengalami kesulitan untuk menghapus ALT sampai saya menggunakan baris perintah berikut, disalin dari @joshskidmore di atas, yang tampaknya melakukan pekerjaan itu (catatan saya harus masuk melalui SSH untuk menjalankan ini karena pengubah yang macet tidak memungkinkan untuk menjalankan perintah secara langsung di mesin 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

Terima kasih @joshskidmore!

Perhatikan juga bahwa kali ini, tidak pernah ada proses penghalang duplikat yang terdeteksi pada klien Linux.

Titik data lain: menggunakan SSH untuk masuk ke mesin linux dan memulai penghalang, masalah tidak terjadi.

Hmm, dan titik data lainnya: menggunakan SSH untuk masuk ke mesin linux dan memulai penghalang, SAAT menahan CTRL-ALT-SHIFT pada keyboard usb sekunder (langsung terhubung ke mesin linux), TIDAK mereproduksi masalah.

Sekarang saya dapat mereproduksi masalah dengan andal:

1. klien linux (laptop), macos server - klien berhasil tersambung ke server (jaringan LAN). bekerja tanpa masalah untuk waktu berapa pun
2. laptop hot-cabut, saat bepergian. di beberapa titik nyalakan wifi dan bekerja langsung pada keyboard & mouse built-in (yaitu, tidak ada koneksi ke server penghalang yang mungkin, jaringan yang berbeda)
3. colokkan kembali ke stasiun dok lagi, wifi masih menyala, penghalang menghubungkan kembali ke server dengan baik
4. beberapa penekanan tombol & klik mouse, hal-hal aneh mulai terjadi. tombol ctrl macet. mengetik menutup atau membuka jendela sesuka hati (mungkin beberapa kombinasi tombol ctrl +), bahkan klik mouse gagal untuk mencapai yang diharapkan (misalnya tidak mungkin untuk menutup jendela atau membuka tab baru di Chrome).

Hanya me-reboot menyelesaikan masalah.

Catatan: ini tidak terjadi saat penghalang tidak berjalan. Saya menyimpulkan bahwa ini bukan masalah Linux / perangkat keras.

Klien:
Linux 4.15.0-107-generik # 108 ~ 16.04.1-Ubuntu SMP Jum 12 Jun 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
Penghalang 2.3.2-snapshot-210cb270
Tanggal Dibangun: Jumat 5 Juni 2020

Server:
Darwin 17.7.0 Versi Kernel Darwin 17.7.0: Rabu 27 Mei 17:00:02 PDT 2020; root: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
Penghalang: 2.3.2-Release-210cb270
Tanggal Dibangun: 3 Oktober 2019

Ketika itu terjadi pada saya, saya tidak sedang memasang atau mencabut apa pun. Kedua laptop tetap menggunakan WiFi (kecuali ada beberapa pemutusan dan koneksi ulang diam-diam yang tidak saya sadari - tetapi saya tidak punya alasan untuk mencurigai adanya pemutusan diam-diam.

Saya memiliki masalah yang sama dengan Anda yang membuat penghalang tidak dapat digunakan ...: '(