github-starred/barrier

Fork 0

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

[GH-ISSUE #1714] Keyboard layout not changing when server uses non-english layout #1268

New issue

Open

opened 2026-05-05 07:41:08 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 07:41:08 -06:00

Owner

Originally created by @Doumor on GitHub (Jul 11, 2022).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1714

What happened?

So, when you select non-english layout on server and try use english layout on client you cant use it, you typing in non-english layout

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

On server(Windows) from winget
On client(Manjaro) from offical reps

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

Linux, Windows

What OS versions are you using?

I tryed only windows as server and manjaro as client

Relevant log output

No response

Any other information

No response

Originally created by @Doumor on GitHub (Jul 11, 2022). Original GitHub issue: https://github.com/debauchee/barrier/issues/1714 ### What happened? So, when you select non-english layout on server and try use english layout on client you cant use it, you typing in non-english layout ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? On server(Windows) from winget On client(Manjaro) from offical reps ### What OSes are you seeing the problem on? (Check all that apply) Linux, Windows ### What OS versions are you using? I tryed only windows as server and manjaro as client ### Relevant log output _No response_ ### Any other information _No response_

gitea-mirror commented

2026-05-05 07:41:11 -06:00

Author

Owner

@Doumor commented on GitHub (Jul 11, 2022):

I didn't see anything like that in the log. There is only information about changing layouts and changing screens. I checked with a combination of windows as a client and linux as a server and this problem did not occur.

@Doumor commented on GitHub (Jul 11, 2022): I didn't see anything like that in the log. There is only information about changing layouts and changing screens. I checked with a combination of windows as a client and linux as a server and this problem did not occur.

gitea-mirror commented

2026-05-05 07:41:12 -06:00

Author

Owner

@P4LaZ100 commented on GitHub (Jul 28, 2022):

I have the same issue . Linux as a server, windows - client . When I try to change the keyboard layout to non-us with the hotkeys, it doesn't change. If I change it manually on the windows, it goes back to us once I hit a key .

@P4LaZ100 commented on GitHub (Jul 28, 2022): I have the same issue . Linux as a server, windows - client . When I try to change the keyboard layout to non-us with the hotkeys, it doesn't change. If I change it manually on the windows, it goes back to us once I hit a key .

gitea-mirror commented

2026-05-05 07:41:13 -06:00

Author

Owner

@MrPuzatyi commented on GitHub (Nov 22, 2022):

Problem is reproducible.
Server: Linux with Gnome or Unity-desktop.
Client: Windows.

When the mouse is on the client (the display is active) - the layout change does not work, when the mouse is on the server (the display is active) - the language is switched successfully.

The problem is in the interaction with the desktop environment, because the problem is not reproducible in KDE or Cinnamon.

Please fix this popular issue for english + non-english customers with the most popular DE (Gnome) @p12tic @walker0643

@MrPuzatyi commented on GitHub (Nov 22, 2022): Problem is reproducible. Server: Linux with Gnome or Unity-desktop. Client: Windows. When the mouse is on the client (the display is active) - the layout change does not work, when the mouse is on the server (the display is active) - the language is switched successfully. The problem is in the interaction with the desktop environment, because the problem is not reproducible in KDE or Cinnamon. Please fix this popular issue for english + non-english customers with the most popular DE (Gnome) @p12tic @walker0643

gitea-mirror commented

2026-05-05 07:41:14 -06:00

Author

Owner

@vladomihov commented on GitHub (Jan 9, 2023):

I have a similar problem.
Server: Windows.
Client: Windows.
Both server and client have the same keyboard layouts.

When the focus is on the client and I switch the language, it switches only in the client language bar. If I type on the client keyboard - it works as expected. The moment I start typing on the server keyboard (still focused on the client) - it changes back the client language to the server one.

Is there any way I can setup a hotkey on the client to also change the language on the server?

@vladomihov commented on GitHub (Jan 9, 2023): I have a similar problem. Server: Windows. Client: Windows. Both server and client have the same keyboard layouts. When the focus is on the client and I switch the language, it switches only in the client language bar. If I type on the client keyboard - it works as expected. The moment I start typing on the server keyboard (still focused on the client) - it changes back the client language to the server one. Is there any way I can setup a hotkey on the client to also change the language on the server?

gitea-mirror commented

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

Author

Owner

@jnihil commented on GitHub (Jan 19, 2023):

I have a related problem.
Barrier server on Debian 11 with an English layout keyboard.
Macos (Ventura) Barrier client, M1 Macbook pro with a Japanese layout keyboard.
All keystrokes are being interpreted as Japanese layout, even if I specify English layout in Macos.

@jnihil commented on GitHub (Jan 19, 2023): I have a related problem. Barrier server on Debian 11 with an English layout keyboard. Macos (Ventura) Barrier client, M1 Macbook pro with a Japanese layout keyboard. All keystrokes are being interpreted as Japanese layout, even if I specify English layout in Macos.

gitea-mirror commented

2026-05-05 07:41:16 -06:00

Author

Owner

@MrPuzatyi commented on GitHub (Jan 19, 2023):

The project is abandoned and there will be no fix

@MrPuzatyi commented on GitHub (Jan 19, 2023): The project is abandoned and there will be no fix