Barrier: सुपर कुंजी (विंडोज़ कुंजी) क्लाइंट पर "दबाए" में फंस जाती है

मेरे पास लिनक्स सर्वर -> लिनक्स क्लाइंट (दोनों आर्क) के साथ भी यह समस्या है। यह अक्सर एक अटक सुपर / मेटा कुंजी है, लेकिन कभी-कभी अन्य संशोधक (शिफ्ट या सीटीटी)। यदि मैं समस्या का अनुभव करता हूं (आइए इस उदाहरण के लिए इसकी पारी कहते हैं), यदि मैं बाधा सर्वर को पुनरारंभ करता हूं, तो क्लाइंट मशीन पर वापस जाएं, चीजें सामान्य हैं। यदि मैं तुरंत होस्ट पर वापस जाता हूं, तो क्लाइंट को वापस, शिफ्ट कुंजी फिर से अटक जाती है। संशोधक क्लाइंट मशीन के भौतिक कीबोर्ड पर "अटका" रहता है। इसे हल करने का विशिष्ट तरीका मेरे लिए सिर्फ क्लाइंट मशीन को रिबूट करना है।

मैं इसे डीबग करने में कैसे मदद कर सकता हूं, इस पर कोई सलाह क्योंकि यह मुझे बिल्कुल पागल बना रहा है। मैं ग्राहक मशीन में SSH करने में सक्षम हूं। मैंने डिबग करने के लिए DISPLAY=:0 xset -q और DISPLAY=:0 xev है और सबकुछ सामान्य लगता है (कोई भी आयोजित संशोधक xset के साथ नहीं दिखाया जा रहा है और क्लाइंट पर "सही" कुंजियों को दबाया जा रहा है (बैरीकेयर के माध्यम से या सीधे)।

बैरियर 2.2.0 के साथ-साथ सिनर्जी 1.10.1 का उपयोग करके यह समस्या मौजूद है।

मैं इसे व्यावहारिक रूप से दैनिक आधार पर प्राप्त कर रहा हूं। मैं क्लाइंट और सर्वर दोनों पर आर्क लिनक्स (हाल ही में अपडेट किया गया) चला रहा हूं। समस्या मुख्य रूप से क्लाइंट को प्रभावित करती है, और जोश की तरह, क्लाइंट मशीन पर बाधा को मारने के बाद भी जारी रहती है।

समस्या को ठीक करने के लिए, मुझे लॉग आउट करना है (अपने TTY के लिए), वापस लॉग इन करें और X को पुनरारंभ करें।

मुझे लगता है कि यह विंडोज क्लाइंट के लिए भी एक समस्या है और कई अलग-अलग संशोधक कुंजी अटक सकती हैं। अगर कोई इसे मज़बूती से पुन: पेश कर सकता है, तो यह मददगार होगा।

मेरे लिए, यह Alt कुंजी है। मेरे पास मेरा पर्यावरण कॉन्फ़िगर किया गया है ताकि विंडोज़ को स्थानांतरित करने और आकार बदलने के लिए Alt (ड्रैग + ड्रैग) का उपयोग किया जाए। जब मैं विंडो को स्क्रीन के किनारे पर खींचता हूँ (यह वह बढ़त जो आम तौर पर मेरे माउस को होस्ट कंप्यूटर पर वापस ले जाने की अनुमति देता है) को ट्रिगर करना संभव है। जब मैं खिड़कियों को इधर-उधर कर रहा होता हूं, तो नजर रखता हूं और देखता हूं कि इसके साथ कुछ करना है (संशोधक जब उपकरणों के बीच चलता है)।

मेरे पास ubuntu सर्वर और विंडोज़ क्लाइंट का उपयोग करके एक मेटा कुंजी अटक गई है। पहली मेटा कुंजी में केवल ubuntu के लिए काम करता है और फिर दोनों के लिए काम नहीं करता है।

क्या कोई डिबगिंग है जिसे हम कर सकते हैं या लॉग कर सकते हैं जो हमें प्रदान कर सकता है जो इस समस्या को ठीक करने में मदद कर सकता है? इस बिंदु पर, मैं किसी और चीज़ पर स्विच करने पर विचार कर रहा हूं, क्योंकि मेरे संपूर्ण X-विंडो सत्र को बंद करने के लिए बस मेरे कीबोर्ड को दैनिक आधार पर काम करने के लिए टिकाऊ नहीं है और समस्या बदतर होती जा रही है।

अगर कोई ऐसी चीज है जो मैं प्रदान कर सकता हूं, तो यह समस्या अब दिन में एक बार मज़बूती से होती है, इसलिए मैं बहुत जल्दी और बार-बार डेटा प्रदान कर सकता हूं।

@DarwinSurvivor - केवल एक चीज जिसे मैंने "रीसेट" करने के लिए पाया है (एक्स को छोड़कर) निम्नलिखित है ... और यह आदर्श नहीं है (बिल्कुल भी):

#!/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 कुंजी अटक गई है, जिसका अर्थ है कि जब मैं क्रोम विंडो पर स्विच करता हूं, तो यह तेजी से फाइलर मेरे सभी टैब को बंद कर देता है जब तक कि पूरी विंडो गायब नहीं हो जाती।

मेरी सुपर-की इस तरह कभी-कभी अटक जाती है। डार्विनसुरिवोर के अनुसार, एक्स जैसी अन्य चाबियां भी अटक सकती हैं, हालांकि मेरी मशीन पर एक या दो के बाद वे चाबी हमेशा अपने आप सही हो जाती हैं। मुझे लगता है कि (wi-fi) lag के कारण मेरा कर्सर जम जाता है और साथ ही साथ ग्राहक 'xxxxxxxxx' से बाहर चला जाता है। सुपर-कुंजी समस्या लगभग स्थायी लगती है, हालांकि एक्स / रिबूटिंग को पुनरारंभ करने के बाहर।

सर्वर: विंडोज 10
क्लाइंट: लिनक्स मिंट 19.1 दालचीनी

मैं ALT कुंजी के साथ एक ही मिलता है।

व्यवहार उलटा हो जाता है। जब मैं होस्ट पर Alt कुंजी दबाता हूं तो क्लाइंट ऐसा व्यवहार करता है जैसे उसे दबाया नहीं गया हो। यह पहले से ही दो बार हुआ। मुझे यकीन नहीं है कि यह पहली बार तय क्या है।

सर्वर: विंडोज 10
क्लाइंट: macOS हाई सिएरा 10.13.6

*अपडेट करें:
जब ALT कुंजी अटक जाती है, तो मैं इसे हल करने के लिए नियंत्रण कुंजी दबा सकता हूं।

मैं एक MacOS होस्ट और लिनक्स टकसाल क्लाइंट के साथ (सुपर कुंजी अटक, कभी-कभी Ctrl कुंजी) का अनुभव करता हूं।

यह ज्ञात कारण के बिना रुक-रुक कर होता है, हालांकि मैं यह मानता हूं कि यह अक्सर स्काइप या गूगल हैंगआउट का उपयोग एक हेड सेट के साथ होता है। कभी-कभी X को पुनरारंभ करने का समाधान करने के लिए, कभी-कभी पूर्ण शटडाउन / रिबूट की आवश्यकता होती है। setxkbmap / xdotool रीसेट करने के लिए प्रतीत नहीं होता है।

सर्वर: macOS हाई सिएरा 10.13.6
क्लाइंट: लिनक्स मिंट 18.3
नेटवर्क: एक ही स्विच, एक ही सबनेट (कोई वाईफ़ाई) के लिए लैन कनेक्शन
बैरियर 2.3.2-रिलीज़-210 c2b70

क्या बैरियर के कारण मेटा कीज़ को क्लाइंट में "दबाया" जाएगा? कुछ घटना होनी चाहिए जो राज्य के परिवर्तन का कारण बनती है और फिर इसे रीसेट होने से रोकती है, मैं शायद भोलेपन से मानता हूं।

क्लाइंट से जारी नहीं की शिफ्ट कुंजी के साथ एक ही समस्या। मैं शीर्षक का नाम बदल दूंगा क्योंकि यह सिर्फ सुपर की तुलना में अधिक संशोधक को प्रभावित करता है।

ऑपरेटिंग सिस्टम
सर्वर: Ubuntu 18.04 (कर्नेल 4.15.0-99-जेनेरिक)
क्लाइंट: उबंटू 18.04 (कर्नेल 5.3.0-51-जेनेरिक)

बैरियर संस्करण
सर्वर: बैरिकेर 2.3.2-13-g9080ce45
क्लाइंट: अवरोध 2.3.2-13-g9080ce45

सिनर्जी में समान मुद्दा मिला https://github.com/symless/synergy-core/issues/6459

यह स्पष्ट करने के लिए छोटा अद्यतन, असंबंधित कुंजी हर बार जब मैं शिफ्ट कुंजी दबाता हूं तो यह नेटवर्क समस्या के कारण होने की संभावना नहीं है।

सर्वर: बैरियर 2.3.2-स्नैपशॉट-210 c2b70 (विंडोज 10 1909)
क्लाइंट: बैरियर 2.3.2-RELEASE-00000000 (आर्क लिनक्स अप टू डेट, मेट 1.24 ओवर Xorg)

उसी, CTRL क्लाइंट क्लाइंट पर अटक गया, CTRL-ALT-DEL दबाते हुए क्लाइंट पर हमला करता है सर्वर (विंडोज) (स्विच स्विच। साइन आउट। कार्य प्रबंधक) मेनू, फिर ESC डेस्कटॉप पर वापस जाने के लिए क्लाइंट पर क्लाइंट के लिए un-sts CTRL कुछ सेकंड (अधिकतम 20 सेकंड), फिर यह अपने आप में फिर से अटक जाता है।

क्लाइंट और सर्वर दोनों पर डीबग 2 के स्तर पर लॉग कुछ भी उपयोगी नहीं दिखाते हैं, बस "प्रवेश / छोड़ने वाली स्क्रीन" संदेश।

बग क्लाइंट को बहुत ही बेकार बना देता है, क्योंकि यह साधारण कीस्ट्रोक्स को ctrl की भागीदारी के कारण कमांड के रूप में व्याख्या करता है।

मैं यह भी अनुभव कर रहा हूँ, दोनों ctrl और क्लाइंट पर पूरी तरह से कुंजी अटक रही है।
क्लाइंट और सर्वर दोनों Ubuntu हैं, दोनों संस्करण 2.3.2-स्नैपशॉट -9080ce45।

डेबियन 2.1.2 + dfsg-1
जब तक मेरे पास अभी भी शिफ्ट की दबाया नहीं जाता है, तब तक क्लाइंट पर दबाया गया शिफ्ट कुंजी अन्य कुंजी को काम करना बंद कर देता है। जैसे कि L टाइप करने के बाद मैं केवल अन्य कैपिटल लेटर्स टाइप कर सकता हूं।
पॉइंटर को सर्वर पर वापस ले जाना और फिर क्लाइंट को वापस सेट करना।

बैरियर 2.3.3 के साथ मेरे दो लिनक्स टकसाल (20 और 19) कंप्यूटरों के बीच नियमित रूप से होता है।

सही बदलाव कुंजी चालू हो जाती है, SHIFT_R लेबल किया जाता है।
कुंजी का एक साधारण प्रेस / रिलीज इस मुद्दे को हल करता है।

अटक गई चाबियों का इस तरह पता लगाया जा सकता है: xev | grep 'keycode .* (.*)'

मेरी पूर्व टिप्पणी के अलावा, लिनक्स क्लाइंट पर निम्न गतिविधियों में से किसी एक के संबंध में अक्सर ऐसा होता है:

• तेज विंडो स्विच (उदाहरण के लिए ऑल-टैब, फास्ट सीक्वेंस में दबाया जाता है, यानी ऑल-टैब / ऑल-टैब / ऑल्ट टैब के विपरीत ऑल-टैब / टैब)। यह आंतरायिक है
• ज़ूम, स्काइप, हैंगआउट जैसे ऑडियो या वीडियो चैट ऐप्स का उपयोग करना। यह कहने में काफी अनुमानित है 7/10 मामले
• वाईफाई से नेटवर्क से जुड़ा होना (ईथरनेट के बजाय)
• वाईफ़ाई कनेक्शन से ईथरनेट पर स्विच करना। 8/10 मामलों में काफी अनुमानित है।

एक बार जब कुंजी को स्टॉक मिल जाता है (मेरे लिए यह Ctrl कुंजी है), अन्य लक्षण कुछ मिनटों के बाद से दिखाई देने लगते हैं जैसे नई टर्मिनल विंडो में रैंडम कैरेक्टर टाइप करने में सक्षम नहीं, कोई कैप या कोई कीबोर्ड इनपुट नहीं। आमतौर पर स्थिति खराब हो जाती है और एकमात्र समाधान रिबूट होता है।

ध्यान दें कि यह कभी-कभी इन गतिविधियों के बिना भी होता है, लेकिन अधिक शायद ही कभी ऐसा होता है।

ग्राहक:
Linux 4.15.0-107-जेनेरिक # 108 ~ 16.04.1-Ubuntu SMP शुक्र जून 12 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
बैरियर 2.3.2-स्नैपशॉट-210 cb270
बिल्ड की तारीख: शुक्रवार 5 जून 2020

सर्वर:
डार्विन 17.7.0 डार्विन कर्नेल संस्करण 17.7.0: बुध 27 मई 17:00:02 पीडीटी 2020; रूट: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
बैरियर: 2.3.2-रिलीज़-210 cb270
बिल्ड तिथि: 3 अक्टूबर 2019

नेटवर्क: ईथरनेट, 1 जीबी, एक ही सबनेट, कभी-कभी वाईफाई (बैरियर अनडू क्लाइंट एक ही राउटर पर होता है, हालांकि सर्वर ईथरनेट, वाईफाई के जरिए क्लाइंट से जुड़ा होता है)

अद्यतन

26 अगस्त 2020 - आवृत्ति में योगदानकर्ता के रूप में वाईफाई कनेक्शन को जोड़ा
28 अगस्त 2020 - आवृत्ति में योगदानकर्ता के रूप में ईथरनेट स्विच में वाईफाई को जोड़ा गया

आज इस समस्या में चल रहा है, मुझे लगता है कि मैं इसे काफी नियमित रूप से पुन: पेश कर सकता हूं। सटीक चरणों को कम करने की कोशिश कर रहा है।

मेरे पास अभी तक यह है:

1. क्लाइंट पर अवरोध शुरू करने के लिए एक शॉर्टकट असाइन करें (मैंने CTRL-ALT-SHIFT-F9 का उपयोग किया है)
2. क्लाइंट से सीधे जुड़े माध्यमिक कीबोर्ड के साथ शॉर्टकट का उपयोग करके अवरोध शुरू करें (ध्यान दें कि यह इससे पहले नहीं चल रहा था)
3. सर्वर से जुड़े प्राथमिक कीबोर्ड के साथ क्लाइंट के लिए स्क्रीन स्विच करें (एक बैरियर शॉर्टकट का उपयोग करके, CTRL-ALT-SHIFT-F12)
4. सर्वर कीबोर्ड पर किसी भी संशोधक कुंजी को दबाएं (वास्तव में आवश्यक नहीं है, लेकिन अपडेट करने के लिए xkbwatch का कारण बनता है)

मैंने पाया कि, कम से कम एक बिंदु पर, लिनक्स क्लाइंट पर मेरे पास कई बैरियर प्रक्रियाएं (बैरिस्टर, लेकिन बैरियर नहीं) चल रही थीं। मैं सब कुछ नए सिरे से शुरू करने जा रहा हूं और देखूंगा कि क्या मैं ऐसे कदमों के एक सेट को संकीर्ण कर सकता हूं जो समस्या को साफ तरीके से पुन: पेश करता है।

ठीक है, मैंने कुछ और परीक्षण किएमज़बूती से समस्या को पुन: पेश करता है:

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 का उपयोग कर रहा हूं, लेकिन जब तक मैं निम्नलिखित कमांड-लाइन का उपयोग नहीं करता, तब तक मुझे एएलटी को प्राप्त करने में परेशानी नहीं हुई , ऊपर

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!

यह भी ध्यान दें कि इस बार, लिनक्स क्लाइंट पर डुप्लिकेट बैरियर प्रक्रिया का पता नहीं लगा।

एक अन्य डेटा-पॉइंट: एसएसएच का उपयोग करके लिनक्स मशीन में प्रवेश करना और अवरोध शुरू करना, समस्या नहीं होती है।

हम्म, और एक अन्य डेटा-पॉइंट: एसएसएच का उपयोग करके लिनक्स मशीन में प्रवेश करना और अवरोध शुरू करना, द्वितीयक यूएसबी कीबोर्ड पर CTRL-ALT-SHIFT को दबाए रखना (सीधे लिनक्स मशीन से जुड़ा), समस्या को पुन: पेश करता है।

मैं अब समस्या का पुन: प्रयास कर सकता हूं:

1. linux client (लैपटॉप), macos सर्वर - क्लाइंट सर्वर (LAN नेटवर्क) से सफलतापूर्वक जुड़ा हुआ है। बिना किसी राशि के समस्याओं के लिए काम करता है
2. गर्म अनप्लग लैपटॉप, इस कदम पर। कुछ बिंदु पर वाईफ़ाई चालू करें और सीधे अंतर्निहित कीबोर्ड और माउस पर काम करें (अर्थात, बाधा सर्वर से कोई संबंध संभव नहीं है, अलग-अलग नेटवर्क)
3. डॉकिंग स्टेशन पर फिर से प्लग करें, वाईफाई अभी भी चालू है, बाधा सर्वर से वापस ठीक जुड़ती है
4. कुछ कीस्ट्रोक्स और माउस पर क्लिक करने से अजीब चीजें होने लगती हैं। ctrl कुंजी अटक गई है। टाइपिंग बंद हो जाती है या (संभवतः कुछ ctrl + कुंजी संयोजन) पर विंडो खोलती है, यहां तक ​​कि माउस क्लिक भी उम्मीद को पूरा करने में विफल रहता है (जैसे कि विंडो बंद करना या क्रोम में नया टैब खोलना असंभव)।

केवल रिबूट करने से समस्या हल हो जाती है।

नोट: यह तब नहीं होता है जब बाधा नहीं चल रही है। मैं यह निष्कर्ष निकालता हूं कि यह लिनक्स / हार्डवेयर समस्या नहीं है।

ग्राहक:
Linux 4.15.0-107-जेनेरिक # 108 ~ 16.04.1-Ubuntu SMP शुक्र जून 12 02:57:13 UTC 2020 x86_64 x86_64 x86_64 GNU / Linux
बैरियर 2.3.2-स्नैपशॉट-210 cb270
बिल्ड की तारीख: शुक्रवार 5 जून 2020

सर्वर:
डार्विन 17.7.0 डार्विन कर्नेल संस्करण 17.7.0: बुध 27 मई 17:00:02 पीडीटी 2020; रूट: xnu 4570.71.80.1 ~ 1 / RELEASE_X86_64 x86_64
बैरियर: 2.3.2-रिलीज़-210 cb270
बिल्ड तिथि: 3 अक्टूबर 2019

जब यह मेरे साथ हुआ, मैं कुछ भी प्लग या अनप्लग नहीं कर रहा था। दोनों लैपटॉप पूरे वाईफाई पर रहे (जब तक कि कुछ साइलेंट डिस्कनेक्ट और रिऐक्शन नहीं थे, जिनके बारे में मुझे जानकारी नहीं है - लेकिन मेरे पास किसी भी साइलेंट डिस्कनेक्ट पर संदेह करने का कोई कारण नहीं है।

मुझे आपके साथ भी वही समस्या है जो अवरोध को अनुपयोगी बनाती है ...: '(