Barrier: يعلق المفتاح الفائق (مفتاح windows) في "الضغط" على العميل

لدي أيضًا هذه المشكلة مع خادم linux -> عميل linux (كلاهما Arch). غالبًا ما يكون مفتاحًا فائقًا / ميتا عالقًا ، ولكن في بعض الأحيان يكون هناك معدِّلات أخرى (التحول أو السيطرة). إذا واجهت المشكلة (دعنا نقول تحولها في هذا المثال) ، إذا أعدت تشغيل خادم الحاجز ، فارجع إلى جهاز العميل ، فالأمور طبيعية. إذا عدت على الفور إلى المضيف ، ثم عدت إلى العميل ، فسيتم تعليق مفتاح shift مرة أخرى. يظل المُعدِّل "عالقًا" على لوحة المفاتيح الفعلية لجهاز العميل أيضًا. الطريقة المعتادة لحل هذه المشكلة هي إعادة تشغيل جهاز العميل فقط.

أي نصيحة حول كيف يمكنني المساعدة في تصحيح هذا سيكون موضع تقدير لأنه يقودني إلى الجنون تمامًا. أنا قادر على SSH في جهاز العميل. لقد جربت DISPLAY=:0 xset -q و DISPLAY=:0 xev للتصحيح ويبدو كل شيء طبيعيًا (لا يتم عرض أي مُعدِّلات معلقة مع xset ويتم الضغط على المفاتيح "الصحيحة" (من خلال الحاجز أو مباشرة) على العميل.

توجد هذه المشكلة باستخدام Barrier 2.2.0 بالإضافة إلى Synergy 1.10.1.

أنا أحصل على هذا بشكل يومي أيضًا. أنا أقوم بتشغيل Arch Linux (تم تحديثه مؤخرًا) على كل من العميل والخادم. يبدو أن المشكلة تؤثر بشكل أساسي على العميل ، ومثل Josh ، تستمر حتى بعد قتل الحاجز على جهاز العميل.

لإصلاح المشكلة ، يتعين علي تسجيل الخروج (إلى TTY الخاص بي) ، وتسجيل الدخول مرة أخرى وإعادة تشغيل X.

أعتقد أن هذه مشكلة لعملاء Windows أيضًا وأن العديد من مفاتيح التعديل المختلفة يمكن أن تتعطل. إذا كان بإمكان أي شخص إعادة إنتاجه بشكل موثوق ، فسيكون ذلك مفيدًا.

بالنسبة لي ، يميل إلى أن يكون مفتاح Alt. لقد تم تكوين بيئتي بحيث يتم استخدام Alt لتحريك النوافذ وتغيير حجمها (Alt + السحب). من المحتمل أن يتم تشغيله عندما أقوم بسحب نافذة إلى حافة الشاشة (الحافة التي تسمح عادةً بالماوس بالرجوع إلى الكمبيوتر المضيف). سأراقب عندما أقوم بتحريك النوافذ وأرى ما إذا كان ذلك له علاقة بها (يتم الاحتفاظ بالمعدل عندما يتحرك الماوس بين الأجهزة).

لديّ مفتاح تعريف عالق باستخدام خادم ubuntu وعميل windows. في البداية ، يعمل مفتاح meta فقط مع 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
العميل: لينكس منت 19.1 سينامون

أحصل على نفس الشيء مع مفتاح ALT.

يصبح السلوك معكوسًا. عندما أضغط على مفتاح Alt في المضيف ، يتصرف العميل كما لو لم يتم الضغط عليه. لقد حدث بالفعل مرتين. لست متأكدًا مما تم إصلاحه في المرة الأولى.

الخادم: Windows 10
العميل: macOS High Sierra 10.13.6

*تحديث:
عندما يتعطل مفتاح ALT ، يمكنني الضغط على مفتاح CONTROL لحل المشكلة.

أواجه نفس الشيء (مفتاح Super عالق ، أحيانًا مفتاح Ctrl) مع مضيف MacOS وعميل Linux Mint.

يحدث هذا بشكل متقطع دون سبب معروف ، على الرغم من أنني لاحظت أنه يحدث غالبًا عند استخدام Skype أو Google Hangout مع مجموعة رأس. لحل مشكلة إعادة تشغيل X في بعض الأحيان ، يلزم أحيانًا إيقاف تشغيل / إعادة تشغيل كامل. لا يبدو أن setxkbmap / xdotool تتم إعادة تعيينها.

الخادم: macOS High Sierra 10.13.6
العميل: Linux Mint 18.3
الشبكة: اتصال LAN بنفس المفتاح ، نفس الشبكة الفرعية (بدون شبكة Wifi)
الحاجز 2.3.2-Release-210c2b70

ما الذي يتسبب في "الضغط" على مفاتيح التعريف في العميل؟ يجب أن يكون هناك حدث ما يتسبب في تغيير الحالة ثم يمنعها من إعادة التعيين ، أفترض ربما بسذاجة.

لم يتم تحرير نفس المشكلة مع مفتاح 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 ، لذا فمن غير المحتمل أن يكون سبب ذلك مشكلة في الشبكة.

الخادم: barrier 2.3.2-snapshot-210c2b70 (Windows 10 1909)
العميل: الحاجز 2.3.2-RELEASE-00000000 (Arch Linux محدث ، Mate 1.24 عبر Xorg)

نفس الشيء ، تم تعليق عميل CTRL على العميل ، والضغط على CTRL-ALT-DEL أثناء استدعاء العميل لقائمة الخادم (Windows) (قفل | SwitchUser | تسجيل الخروج | إدارة المهام) ، ثم ESC للعودة إلى سطح المكتب un-stucks CTRL على العميل بضع ثوان (20 ثانية على الأكثر) ، ثم يتعطل مرة أخرى من تلقاء نفسه.

لا تظهر السجلات على مستوى Debug2 على كل من العميل والخادم شيئًا مفيدًا ، فقط رسائل "دخول / مغادرة الشاشة".

يجعل الخطأ العميل غير قابل للاستخدام إلى حد كبير ، لأنه يفسر ضغطات المفاتيح البسيطة على أنها أوامر بسبب تدخل ctrl.

أواجه هذا أيضًا ، مع تعطل مفتاحي ctrl و alt على العميل.
العميل والخادم كلاهما من Ubuntu ، كلاهما الإصدار 2.3.2-snapshot-9080ce45.

ديبيان 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 بدلاً من alt-tab-tab-tab). هذا متقطع
• باستخدام تطبيقات الدردشة الصوتية أو المرئية مثل Zoom و Skype و Hangout. هذا يمكن التنبؤ به تمامًا في حالات 7/10
• الاتصال بالشبكة عبر wifi (بدلاً من ethernet)
• التبديل من اتصال wifi إلى 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

الخادم:
داروين 17.7.0 إصدار Darwin Kernel 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

الشبكة: إيثرنت ، 1 جيجابايت ، نفس الشبكة الفرعية ، وأحيانًا شبكة wifi (الحاجز والعميل موجودان على نفس الموجه ، ولكن الخادم متصل عبر إيثرنت ، والعميل عبر شبكة wifi)

محدث

26 أغسطس 2020 - تمت إضافة اتصال wifi كمساهم في التردد
28 أغسطس 2020 - تمت إضافة wifi إلى محول إيثرنت كمساهم في التردد

عند مواجهة هذه المشكلة اليوم ، أعتقد أنه يمكنني إعادة إنتاجها بانتظام. محاولة تضييق الخطوات الدقيقة.

ما لدي حتى الآن هو هذا:

1. قم بتعيين اختصار لبدء الحاجز على العميل (استخدمت CTRL-ALT-SHIFT-F9)
2. بدء حاجز باستخدام الاختصار مع لوحة مفاتيح ثانوية متصلة مباشرة بالعميل (لاحظ أنه لم يكن يعمل قبل ذلك)
3. تبديل الشاشة إلى العميل باستخدام لوحة المفاتيح الأساسية المتصلة بالخادم (باستخدام اختصار الحاجز ، CTRL-ALT-SHIFT-F12)
4. اضغط على أي مفتاح تعديل على لوحة مفاتيح الخادم (في الواقع ليس ضروريًا ، ولكنه يتسبب في تحديث xkbwatch)

لقد اكتشفت ، على الأقل في مرحلة واحدة ، أنه كان لدي عدة عمليات حاجز قيد التشغيل (ليس حاجزًا ، ولكن حاجزًا) ، على عميل 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 وبدء الحاجز ، لا تحدث المشكلة.

Hmm ، ونقطة بيانات أخرى: استخدام SSH لتسجيل الدخول إلى جهاز linux وبدء الحاجز ، أثناء الضغط باستمرار على CTRL-ALT-SHIFT على لوحة مفاتيح USB الثانوية (المتصلة مباشرة بجهاز linux) ، يؤدي إلى إعادة إنتاج المشكلة.

يمكنني الآن إعادة إنتاج المشكلة بشكل موثوق:

1. عميل Linux (كمبيوتر محمول) ، خادم macos - العميل متصل بنجاح بالخادم (شبكة LAN). يعمل بدون مشاكل لأي فترة زمنية
2. جهاز كمبيوتر محمول قابل للفصل أثناء التنقل. في مرحلة ما ، قم بتشغيل wifi واعمل مباشرة على لوحة مفاتيح وماوس مدمجين (أي ، لا يوجد اتصال بخادم الحاجز ، شبكة مختلفة)
3. قم بتوصيله مرة أخرى بمحطة الإرساء مرة أخرى ، ولا يزال wifi قيد التشغيل ، ويتصل الحاجز مرة أخرى بالخادم على ما يرام
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

الخادم:
داروين 17.7.0 إصدار Darwin Kernel 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

عندما حدث لي ذلك ، لم أكن أقوم بتوصيل أو فصل أي شيء. بقي كلا الجهازين المحمولين على شبكة WiFi طوال الوقت (ما لم يكن هناك بعض عمليات قطع الاتصال وإعادة الاتصال الصامتة التي لست على دراية بها - لكن ليس لدي سبب للاشتباه في أي انقطاع صامت.

لدي نفس المشكلة مثلك التي تجعل الحاجز غير قابل للاستخدام ...: '(