github-starred/barrier

Fork 0

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

[GH-ISSUE #366] Capslock not forwarded #293

New issue

Open

opened 2026-05-05 05:58:23 -06:00 by gitea-mirror · 13 comments

gitea-mirror commented

2026-05-05 05:58:23 -06:00

Owner

Originally created by @xgdgsc on GitHub (Jul 21, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/366

Operating Systems

Server: Windows 10 737504

Client: Ubuntu 18.04

READ ME, DELETE ME: On Windows, hold the Windows key and press 'r', type 'winver' and hit return to get your OS version. On Mac, hit the Apple menu (top left of the screen) and check 'About this Mac'. Linux users... you know what you're using ;)

Barrier Version

2.3.0

Steps to reproduce bug

Switch to Ubuntu and Click Caps Lock on server in windows.
Real Caps lock is pressed on windows instead of forwarding to ubuntu.

Other info

Since I usually use caps as ctrl. This is a deal breaker for me. I also runs autohotkey on windows to set caps lock as ctrl. Exiting autohotkey doesn't fix it for me. I also tried using the "Fix Caps Lock" option in server config on both screens and it doesn' t change the result, still capslock is pressed on server.

Originally created by @xgdgsc on GitHub (Jul 21, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/366 ### Operating Systems ### Server: Windows 10 737504 Client: Ubuntu 18.04 **READ ME, DELETE ME**: On Windows, hold the Windows key and press 'r', type 'winver' and hit return to get your OS version. On Mac, hit the Apple menu (top left of the screen) and check 'About this Mac'. Linux users... you know what you're using ;) ### Barrier Version ### 2.3.0 ### Steps to reproduce bug ### 1. Switch to Ubuntu and Click Caps Lock on server in windows. 2. Real Caps lock is pressed on windows instead of forwarding to ubuntu. ### Other info ### Since I usually use caps as ctrl. This is a deal breaker for me. I also runs autohotkey on windows to set caps lock as ctrl. Exiting autohotkey doesn't fix it for me. I also tried using the "Fix Caps Lock" option in server config on both screens and it doesn' t change the result, still capslock is pressed on server.

gitea-mirror added the

bug

windows

linux

labels 2026-05-05 05:58:23 -06:00

gitea-mirror commented

2026-05-05 05:58:27 -06:00

Author

Owner

@xgdgsc commented on GitHub (Jul 21, 2019):

The reverse server-ubuntu client-windows config doesn' t have this issue.

@xgdgsc commented on GitHub (Jul 21, 2019): The reverse server-ubuntu client-windows config doesn' t have this issue.

gitea-mirror commented

2026-05-05 05:58:29 -06:00

Author

Owner

@xgdgsc commented on GitHub (Jul 25, 2019):

A manjaro-server and ubuntu-client works well.

@xgdgsc commented on GitHub (Jul 25, 2019): A manjaro-server and ubuntu-client works well.

gitea-mirror commented

2026-05-05 05:58:31 -06:00

Author

Owner

@endrift commented on GitHub (Oct 15, 2020):

I use caps lock for compose key on Linux, and have a similar problem.

@endrift commented on GitHub (Oct 15, 2020): I use caps lock for compose key on Linux, and have a similar problem.

gitea-mirror commented

2026-05-05 05:58:34 -06:00

Author

Owner

@Dragovorn commented on GitHub (Dec 18, 2020):

I noticed something running a Void Linux Server and Windows Client, when caps-lock is pushed it actually sends the button press once before a new key press and once after. So if caps lock is on and I hit A, the client would acts as so: Caps Lock -> A -> Caps Lock. Was very frustrating considering I use caps lock as a keybind in a game.

@Dragovorn commented on GitHub (Dec 18, 2020): I noticed something running a Void Linux Server and Windows Client, when caps-lock is pushed it actually sends the button press once before a new key press and once after. So if caps lock is on and I hit A, the client would acts as so: Caps Lock -> A -> Caps Lock. Was very frustrating considering I use caps lock as a keybind in a game.

gitea-mirror commented

2026-05-05 05:58:37 -06:00

Author

Owner

@jose1711 commented on GitHub (Apr 21, 2021):

FWIW barrier running both on Arch Linux, Caps-lock is not detected by xev running on the client (other keys are detected and shown properly). What it means (maybe as a side effect) is that things keyboard layouts that read Caps-lock state are only partially usable.

Here's one example:
keyboard layout: https://gitlab.com/vojta_vogo/vok/raw/master/xorg/vok_sk
key definition:

    key <AE04> {	[	  4,	dollar,		ccaron,		Ccaron		]	};

So I get:

4 when I hit 4 alone
$ when I hit Shift + 4
č (lowercase) when I hit AltGr + 4
Č (uppercase) when I hit AltGr + 4 while CapsLock is active

On the client however the last example is not working the same way and it always produces lowercase ccaron (č) symbol quite likely due to the fact that Caps Lock state is not propagated to the client.

@jose1711 commented on GitHub (Apr 21, 2021): FWIW `barrier` running both on Arch Linux, Caps-lock is not detected by `xev` running on the client (other keys are detected and shown properly). What it means (maybe as a side effect) is that things keyboard layouts that read Caps-lock state are only partially usable. Here's one example: keyboard layout: https://gitlab.com/vojta_vogo/vok/raw/master/xorg/vok_sk key definition: ``` key <AE04> { [ 4, dollar, ccaron, Ccaron ] }; ``` So I get: - `4` when I hit <kbd>4</kbd> alone - `$` when I hit <kbd>Shift</kbd> + <kbd>4</kbd> - `č` (lowercase) when I hit <kbd>AltGr</kbd> + <kbd>4</kbd> - `Č` (uppercase) when I hit <kbd>AltGr</kbd> + <kbd>4</kbd> while <kbd>CapsLock</kbd> is active On the client however the last example is not working the same way and it always produces lowercase `ccaron` (`č`) symbol quite likely due to the fact that Caps Lock state is not propagated to the client.

gitea-mirror commented

2026-05-05 05:58:39 -06:00

Author

Owner

@inebritov commented on GitHub (Feb 21, 2022):

I'm using caps as layout switch (on logitech mx keys) and any system I tested (win10/mac12/ubuntu20) either as server or as client do have the issue. Seems this bug affects synergy too.

@inebritov commented on GitHub (Feb 21, 2022): I'm using caps as layout switch (on logitech mx keys) and any system I tested (win10/mac12/ubuntu20) either as server or as client do have the issue. Seems this bug affects synergy [too](https://github.com/symless/synergy-core/issues/6830).

gitea-mirror commented

2026-05-05 05:58:41 -06:00

Author

Owner

@davzaman commented on GitHub (Apr 6, 2022):

Windows server with mac client has this problem pretty frustrating as I can't untoggle caps unless I move my mouse back to the client and then untoggle it and come back

@davzaman commented on GitHub (Apr 6, 2022): Windows server with mac client has this problem pretty frustrating as I can't untoggle caps unless I move my mouse back to the client and then untoggle it and come back

gitea-mirror commented

2026-05-05 05:58:42 -06:00

Author

Owner

@Adnios commented on GitHub (Jun 17, 2022):

Same issue when windows10 server, manjaro client

@Adnios commented on GitHub (Jun 17, 2022): Same issue when windows10 server, manjaro client

gitea-mirror commented

2026-05-05 05:58:43 -06:00

Author

Owner

@fiftyfathoms commented on GitHub (Jul 16, 2022):

I have the same issue with Windows server and windows client. The server uses autohotkey for mapping ctrl to caps lock. The client can't recognize this key press._

@fiftyfathoms commented on GitHub (Jul 16, 2022): I have the same issue with Windows server and windows client. The server uses autohotkey for mapping ctrl to caps lock. The client can't recognize this key press._

gitea-mirror commented

2026-05-05 05:58:46 -06:00

Author

Owner

@Malvineous commented on GitHub (Dec 17, 2025):

Is there any workaround for this? Every time I accidentally press Caps Lock while a client machine has the focus, every second letter I type is in capitals and the space bar stops working, sOeVeRyThInGiTyPeLoOkSwEiRd. Sometimes if I press Caps Lock a bunch of times it returns to normal, but otherwise the only workaround I've found is to restart X11 on the affected machine, or to physically plug in the keyboard and press the Caps Lock to switch it back off again. Using xdotool to send key codes for Caps Lock has no effect, and neither does restarting the Barrier server and client. I think the problem is that the first Caps Lock press switches Caps Lock on, on the remote machine, but then it's not possible to switch it back off again without pressing it on a physical keyboard.

@Malvineous commented on GitHub (Dec 17, 2025): Is there any workaround for this? Every time I accidentally press Caps Lock while a client machine has the focus, every second letter I type is in capitals and the space bar stops working, sOeVeRyThInGiTyPeLoOkSwEiRd. Sometimes if I press Caps Lock a bunch of times it returns to normal, but otherwise the only workaround I've found is to restart X11 on the affected machine, or to physically plug in the keyboard and press the Caps Lock to switch it back off again. Using `xdotool` to send key codes for Caps Lock has no effect, and neither does restarting the Barrier server and client. I think the problem is that the first Caps Lock press switches Caps Lock on, on the remote machine, but then it's not possible to switch it back off again without pressing it on a physical keyboard.

gitea-mirror commented

2026-05-05 05:58:47 -06:00

Author

Owner

@nbolton commented on GitHub (Dec 17, 2025):

Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork).

https://github.com/deskflow/deskflow
https://github.com/input-leap/input-leap

If this is still an issue in those projects, we would appreciate a cross-post of this issue.

@nbolton commented on GitHub (Dec 17, 2025): Barrier is no longer in development. Check out Deskflow (upstream) or Input Leap (fork). https://github.com/deskflow/deskflow https://github.com/input-leap/input-leap If this is still an issue in those projects, we would appreciate a cross-post of this issue.

gitea-mirror commented

2026-05-05 05:58:51 -06:00

Author

Owner

@Malvineous commented on GitHub (Dec 17, 2025):

Oh sorry I didn't realise, thanks for the heads up!

@Malvineous commented on GitHub (Dec 17, 2025): Oh sorry I didn't realise, thanks for the heads up!

gitea-mirror commented

2026-05-05 05:58:52 -06:00

Author

Owner

@nbolton commented on GitHub (Dec 17, 2025):

Oh sorry I didn't realise, thanks for the heads up!

Most people don't. Wouldn't it be useful if the maintainers of this project archived it and let people know there are active projects?

@nbolton commented on GitHub (Dec 17, 2025): > Oh sorry I didn't realise, thanks for the heads up! Most people don't. Wouldn't it be useful if the maintainers of this project archived it and let people know there are active projects?

gitea-mirror referenced this issue

2026-05-05 07:57:15 -06:00

[PR #303] [MERGED] Azure pipelines #1597