github-starred/barrier

Fork 0

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

[GH-ISSUE #1298] Keyboard layout changes from preset to US on server and client independently after screen lock/suspend #1033

New issue

Open

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

gitea-mirror commented

2026-05-05 07:24:02 -06:00

Owner

Originally created by @rengolin on GitHub (Sep 23, 2021).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1298

What happened?

Both my machines have UK keyboard set and nothing else. Server is Windows 10, client is either Ubuntu or Arch Linux.

I can't remember it happening on Ubuntu, running Gnome. But on Arch, running i3+gnome, it's on average once a day.

I set up my keyboard on i3 with:

exec_always --no-startup-id setxkbmap gb -option ctrl:nocaps

Default server config + "sync screen savers" and "clipboard sharing".

When I come back from suspend, the keyboard resets to US (" and @ swapped, for example). Most of the time, this happens on the client side, but sometimes it does happen on the server side, which tells me it isn't a "Linux problem" or a "Windows problem".

This also happens, albeit less frequently, when I lock from the client (locking both client and server), then unlock them separately.

Work Arounds:

Restart server, restart client
On Arch, restart i3 config (which runs setkbdmap again)

I haven't yet figured out the right sequence of the action above, because every time it happens, I'm in the middle of something and I get really upset, and try all things at once. :)

I have a physical KVM that I use to flip between machines and reset everything, which is quite helpful in this case, and the one where the keyboard goes dead.

Version

v2.3.3

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

Windows 10: downloaded from Github
Linux: installed from packages. Arch from community/barrier not aur/barrier-git.

What OSes are you seeing the problem on? (Check all that apply)

Linux, Windows

What OS versions are you using?

Windows 10 latest updates
Arch Linux latest updates
Ubuntu 20.04 LTS

Relevant log output

Logs don't show keymap change at all

Any other information

I've searched for this problem on the issues but didn't find any existing one like that.

However, I did find some saying the keyboard stops responding and that also happens to me.

From the behaviour I see, I believe what happens is that some meta key gets stuck, so all key presses are meta+key which don't usually output anything. I have looked at what happens on the WM and I think most of the time I get the Windows key locked.

Originally created by @rengolin on GitHub (Sep 23, 2021). Original GitHub issue: https://github.com/debauchee/barrier/issues/1298 ### What happened? Both my machines have UK keyboard set and nothing else. Server is Windows 10, client is either Ubuntu or Arch Linux. I can't remember it happening on Ubuntu, running Gnome. But on Arch, running i3+gnome, it's on average once a day. I set up my keyboard on i3 with: ``` exec_always --no-startup-id setxkbmap gb -option ctrl:nocaps ``` Default server config + "sync screen savers" and "clipboard sharing". When I come back from suspend, the keyboard resets to US (" and @ swapped, for example). Most of the time, this happens on the client side, but sometimes it does happen on the server side, which tells me it isn't a "Linux problem" or a "Windows problem". This also happens, albeit less frequently, when I lock from the client (locking both client and server), then unlock them separately. Work Arounds: * Restart server, restart client * On Arch, restart i3 config (which runs setkbdmap again) I haven't yet figured out the right sequence of the action above, because every time it happens, I'm in the middle of something and I get really upset, and try all things at once. :) I have a physical KVM that I use to flip between machines and reset everything, which is quite helpful in this case, and the one where the keyboard goes dead. ### Version v2.3.3 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? Windows 10: downloaded from Github Linux: installed from packages. Arch from `community/barrier` not `aur/barrier-git`. ### What OSes are you seeing the problem on? (Check all that apply) Linux, Windows ### What OS versions are you using? Windows 10 latest updates Arch Linux latest updates Ubuntu 20.04 LTS ### Relevant log output ```shell Logs don't show keymap change at all ``` ### Any other information I've searched for this problem on the issues but didn't find any existing one like that. However, I did find some saying the keyboard stops responding and that also happens to me. From the behaviour I see, I believe what happens is that some meta key gets stuck, so all key presses are meta+key which don't usually output anything. I have looked at what happens on the WM and I think most of the time I get the Windows key locked.

gitea-mirror added the

bug

label 2026-05-05 07:24:02 -06:00

gitea-mirror commented

2026-05-05 07:24:04 -06:00

Author

Owner

@rengolin commented on GitHub (Jan 26, 2022):

Update: the switch still happens even if barrier isn't running. It's a known KVM issue for window managers that don't have centralised configuration (like i3).

See: https://bbs.archlinux.org/viewtopic.php?id=249498

I'm guessing the same is true when barrier suspends on the server, or it may be linked to the fact that the client also suspended.

I'm not sure the KVM is affecting how barrier works, because I use both quite profusely, so it's hard to know what the underlying cause really is.

The other issues that mention this seem not to be related to KVM, so, perhaps it's a more common issue.

@rengolin commented on GitHub (Jan 26, 2022): Update: the switch still happens even if barrier isn't running. It's a known KVM issue for window managers that don't have centralised configuration (like i3). See: https://bbs.archlinux.org/viewtopic.php?id=249498 I'm guessing the same is true when barrier suspends on the server, or it may be linked to the fact that the client also suspended. I'm not sure the KVM is affecting how barrier works, because I use both quite profusely, so it's hard to know what the underlying cause really is. The other issues that mention this seem not to be related to KVM, so, perhaps it's a more common issue.

No labels

Rows
Columns