github-starred/barrier

Fork 0

mirror of https://github.com/debauchee/barrier.git synced 2026-05-15 14:16:02 -06:00

[GH-ISSUE #423] Caps Lock for layout change #327

New issue

Open

opened 2026-05-05 06:02:45 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 06:02:45 -06:00

Owner

Originally created by @mFoxRU on GitHub (Sep 3, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/423

Operating Systems

Server: Windows 10 1803

Client: Debian GNU/Linux 10 (buster) with Mate 1.20.4

Barrier Version

2.3.1

Steps to reproduce bug

Have more then one layout on Linux client (I have English and Russian)
Bind layout change to Caps Lock key on Linux client.
Manually select English layout on both Server and Client (i.e. using panel widget).
Press Caps Lock button while on Linux Client and press any button a couple of times, for example q (it has letter й on Russian layout).
Bug 1: Instead of qqqq sequence (layout didn't change) or йййй sequence (layout did change) it will generate qЙqЙ sequence (odd characters are from original layout and even characters are capitalized and from second layout).
5.1. Pressing Caps Lock again while even number of keys were pressed returns input to proper behavior.
5.2. Bug 2: Pressing Caps Lock again while odd number of keys were pressed locks input to capitalized keys of second layout.
5.2.1. Bug 3: switching to Server and back to Client completely disables text input from barrier (but hotkeys still work). Reloading or restarting barrier doesn't help. Using keyboard attached to client produces capitalized characters. The only way to enable input with barrier is to disable CAPS (Shift-CapsLock on client-attached keyboard)

Other info

This bug is probably a weird combination of #45 and #366.

Originally created by @mFoxRU on GitHub (Sep 3, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/423 ### Operating Systems ### Server: Windows 10 1803 Client: Debian GNU/Linux 10 (buster) with Mate 1.20.4 ### Barrier Version ### 2.3.1 ### Steps to reproduce bug ### 1. Have more then one layout on Linux client (I have English and Russian) 2. Bind layout change to Caps Lock key on Linux client. 3. Manually select English layout on both Server and Client (i.e. using panel widget). 4. Press Caps Lock button while on Linux Client and press any button a couple of times, for example `q` (it has letter `й` on Russian layout). 5. **Bug 1:** Instead of `qqqq` sequence (layout didn't change) or `йййй` sequence (layout did change) it will generate `qЙqЙ` sequence (odd characters are from original layout and even characters are capitalized and from second layout). 5.1. Pressing Caps Lock again while even number of keys were pressed returns input to proper behavior. 5.2. **Bug 2**: Pressing Caps Lock again while odd number of keys were pressed locks input to capitalized keys of second layout. 5.2.1. **Bug 3**: switching to Server and back to Client completely disables text input from barrier (but hotkeys still work). Reloading or restarting barrier doesn't help. Using keyboard attached to client produces capitalized characters. The only way to enable input with barrier is to disable CAPS (Shift-CapsLock on client-attached keyboard) ### Other info ### This bug is probably a weird combination of #45 and #366.

gitea-mirror added the

bug

label 2026-05-05 06:02:46 -06:00

gitea-mirror commented

2026-05-05 06:02:49 -06:00

Author

Owner

@mFoxRU commented on GitHub (Sep 3, 2019):

Also Bug 4: After restoring characters input (Bug 3) barrier MAY START to completely ignore selected layout on Client and print characters using English layout while using keyboard attached to Client print characters depending on layout.

@mFoxRU commented on GitHub (Sep 3, 2019): Also **Bug 4**: After restoring characters input (Bug 3) barrier MAY START to completely ignore selected layout on Client and print characters using English layout while using keyboard attached to Client print characters depending on layout.

No labels

Rows
Columns