github-starred/barrier

Fork 0

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

[GH-ISSUE #1709] English US keyboard layout on client #1264

New issue

Open

opened 2026-05-05 07:40:05 -06:00 by gitea-mirror · 7 comments

gitea-mirror commented

2026-05-05 07:40:05 -06:00

Owner

Originally created by @Cris70 on GitHub (Jul 4, 2022).
Original GitHub issue: https://github.com/debauchee/barrier/issues/1709

What happened?

Barrier v2.40 on both server and client.
OpenSuse Tumbleweed on both server and client, both with KDE plasma.
Italian keyboard layout on both server and client.
When I write on the client, keyboard acts as if it was configured with English US layout.
Keyboard on the server works normally.

Version

v2.4.0

Git commit hash (if applicable)

No response

If applicable, where did you install Barrier from?

OpenSuse Tumbleweed repo

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

Linux

What OS versions are you using?

OpenSuse Tumbleweed 20220702

Relevant log output

No response

Any other information

No response

Originally created by @Cris70 on GitHub (Jul 4, 2022). Original GitHub issue: https://github.com/debauchee/barrier/issues/1709 ### What happened? Barrier v2.40 on both server and client. OpenSuse Tumbleweed on both server and client, both with KDE plasma. Italian keyboard layout on both server and client. When I write on the client, keyboard acts as if it was configured with English US layout. Keyboard on the server works normally. ### Version v2.4.0 ### Git commit hash (if applicable) _No response_ ### If applicable, where did you install Barrier from? OpenSuse Tumbleweed repo ### What OSes are you seeing the problem on? (Check all that apply) Linux ### What OS versions are you using? OpenSuse Tumbleweed 20220702 ### Relevant log output _No response_ ### Any other information _No response_

gitea-mirror commented

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

Author

Owner

@lcomrade commented on GitHub (Aug 10, 2022):

I see the same problem. Server - Debian 11 (Gnome 3), client - Debian 11 (i3wm). Barrier version is 2.3.3 everywhere.

@lcomrade commented on GitHub (Aug 10, 2022): I see the same problem. Server - Debian 11 (Gnome 3), client - Debian 11 (i3wm). Barrier version is 2.3.3 everywhere.

gitea-mirror commented

2026-05-05 07:40:09 -06:00

Author

Owner

@orgrim commented on GitHub (Aug 10, 2022):

Hi,

I've got the same issue, but with my French keyboard on a client in Debian 11 with i3vm. Starting barrier with LANG=fr_FR.UTF-8 fixed it.

$ LANG=fr_FR.UTF-8 barrier

So I guess you could try with it_IT.UTF-8, or the locale name relevant to your setup?

Hope this helps.

@orgrim commented on GitHub (Aug 10, 2022): Hi, I've got the same issue, but with my French keyboard on a client in Debian 11 with i3vm. Starting barrier with LANG=fr_FR.UTF-8 fixed it. ``` $ LANG=fr_FR.UTF-8 barrier ``` So I guess you could try with it_IT.UTF-8, or the locale name relevant to your setup? Hope this helps.

gitea-mirror commented

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

Author

Owner

@orgrim commented on GitHub (Aug 10, 2022):

Well it does not work too well, I have to reload the client and accent key does not work properly...

@orgrim commented on GitHub (Aug 10, 2022): Well it does not work too well, I have to reload the client and accent key does not work properly...

gitea-mirror commented

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

Author

Owner

@enyone commented on GitHub (Nov 19, 2022):

Same issue here. Barrier v2.4.0 on both server Windows 10 and client Fedora 36.

Finnish/Scandinavian letters åäöÅÄÖ not working either.

At client log when pressing key ö on server.

[2022-11-19T23:04:24] DEBUG1: recv key down id=0x000000f6, mask=0x2000, button=0x0027
[2022-11-19T23:04:24] DEBUG1: mapKey 00f6 (246) with mask 2000, start state: 2000
[2022-11-19T23:04:24] DEBUG1: find best:  2000 2000
[2022-11-19T23:04:24] DEBUG1: no mapping for key 00f6
[2022-11-19T23:04:24] DEBUG1: recv key up id=0x000000f6, mask=0x2000, button=0x0027

@enyone commented on GitHub (Nov 19, 2022): Same issue here. Barrier v2.4.0 on both server **Windows 10** and client **Fedora 36**. Finnish/Scandinavian letters `åäöÅÄÖ` not working either. At client log when pressing key `ö` on server. ``` [2022-11-19T23:04:24] DEBUG1: recv key down id=0x000000f6, mask=0x2000, button=0x0027 [2022-11-19T23:04:24] DEBUG1: mapKey 00f6 (246) with mask 2000, start state: 2000 [2022-11-19T23:04:24] DEBUG1: find best: 2000 2000 [2022-11-19T23:04:24] DEBUG1: no mapping for key 00f6 [2022-11-19T23:04:24] DEBUG1: recv key up id=0x000000f6, mask=0x2000, button=0x0027 ```

gitea-mirror commented

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

Author

Owner

@Mi605 commented on GitHub (Mar 19, 2023):

Same issue here. Keybord on client is reset to English language as soon keying in from the server keyboard (which has the very non-English keyboard language layout setting as the client). Only after using the client keyboard it can get reset to proper language which was set before. The moment you type again from Server keyboard to client, the language on client is reset to US_English again.
Additional observation: As long mouse is on client, keyboard switcher fbxkb is blocked and nailed to US_English. Neither tray icon nor keyboard shortcut for keyboard layout switching won't work anymore. Checking the keyboard layout the same time, the proper language is still properly set up, while barrier obviously keeps proper keyboard language layout from being used on the client.

The temporal fix described by @orgrim ( $ LANG=fr_FR.UTF-8 barrier ) doesn't work for me unfortunately. Have started this way both, server and client side, without any success.

Bug confirmed for barrier 2.4.0 installed from default debian repos on debian derivat antiX 23 (debian bookworm based), 22, 21 (debian bullseye based both). Fails in all OS versions and all combinations of versions. Tests running on IceWM and Fluxbox and JWM window managers with same results. Same on 32bit and 64bit machines. Same result with barrier 2.3.3 on client side.

Please fix this urgently. This bug renders barrier unusable for foreign language users.

$ LANG=C apt-cache policy barrier
barrier:
  Installed: 2.4.0+dfsg-3~bpo11+1
  Candidate: 2.4.0+dfsg-3~bpo11+1
  Version table:
 *** 2.4.0+dfsg-3~bpo11+1 100
        100 http://deb.debian.org/debian bullseye-backports/main i386 Packages
        100 /var/lib/dpkg/status
     2.3.3+dfsg-1.1 500
        500 http://ftp.de.debian.org/debian bullseye/main i386 Packages

$ LANG=C apt-cache policy barrier
barrier:
  Installed: 2.4.0+dfsg-3
  Candidate: 2.4.0+dfsg-3
  Version table:
 *** 2.4.0+dfsg-3 500
        500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages
        100 /var/lib/dpkg/status

@Mi605 commented on GitHub (Mar 19, 2023): Same issue here. Keybord on client is reset to English language as soon keying in from the server keyboard (which has the very non-English keyboard language layout setting as the client). Only after using the client keyboard it can get reset to proper language which was set before. The moment you type again from Server keyboard to client, the language on client is reset to US_English again. Additional observation: As long mouse is on client, keyboard switcher fbxkb is blocked and nailed to US_English. Neither tray icon nor keyboard shortcut for keyboard layout switching won't work anymore. Checking the keyboard layout the same time, the proper language is still properly set up, while barrier obviously keeps proper keyboard language layout from being used on the client. The temporal fix described by @orgrim ( _$ LANG=fr_FR.UTF-8 barrier_ ) doesn't work for me unfortunately. Have started this way both, server and client side, without any success. Bug confirmed for barrier 2.4.0 installed from default debian repos on debian derivat antiX 23 (debian bookworm based), 22, 21 (debian bullseye based both). Fails in all OS versions and all combinations of versions. Tests running on IceWM and Fluxbox and JWM window managers with same results. Same on 32bit and 64bit machines. Same result with barrier 2.3.3 on client side. Please fix this urgently. This bug renders barrier unusable for foreign language users. ``` $ LANG=C apt-cache policy barrier barrier: Installed: 2.4.0+dfsg-3~bpo11+1 Candidate: 2.4.0+dfsg-3~bpo11+1 Version table: *** 2.4.0+dfsg-3~bpo11+1 100 100 http://deb.debian.org/debian bullseye-backports/main i386 Packages 100 /var/lib/dpkg/status 2.3.3+dfsg-1.1 500 500 http://ftp.de.debian.org/debian bullseye/main i386 Packages ``` ``` $ LANG=C apt-cache policy barrier barrier: Installed: 2.4.0+dfsg-3 Candidate: 2.4.0+dfsg-3 Version table: *** 2.4.0+dfsg-3 500 500 http://ftp.de.debian.org/debian bookworm/main amd64 Packages 100 /var/lib/dpkg/status ```

gitea-mirror commented

2026-05-05 07:40:18 -06:00

Author

Owner

@Mi605 commented on GitHub (Mar 19, 2023):

Additional finding>
When switching the server side kezboard lazout to wrong US/English language instead of proper language, on the client side the proper kezboard lazout is applied, even when wrong US English lazout is displazed in status bar.

Sorrz for the mistzpings, barrier wouldn|t allow me to switch back to proper kezboard lazout, and on the US English lazout I can|t find the proper kezs needed.

Please fix it high prioritz.

@Mi605 commented on GitHub (Mar 19, 2023): Additional finding> When switching the server side kezboard lazout to wrong US/English language instead of proper language, on the client side the proper kezboard lazout is applied, even when wrong US English lazout is displazed in status bar. Sorrz for the mistzpings, barrier wouldn|t allow me to switch back to proper kezboard lazout, and on the US English lazout I can|t find the proper kezs needed. Please fix it high prioritz.

gitea-mirror commented

2026-05-05 07:40:19 -06:00

Author

Owner

@csarn commented on GitHub (Apr 5, 2024):

I have the same problem (where the layout I want is german, but barrierc switches it to US). But I found a workaround: After barrier has connected, I run setxkbmap de nodeadkeys on the client, and then it works as expected. A little bit annoying still, but I can live with it.
In case you really need this fixed, try to switch to https://github.com/input-leap/input-leap, which is a fork of barrier that is actually still developed. Don't expect anything to change in barrier, the project seems dead. Last commit is more than 2 years ago.

@csarn commented on GitHub (Apr 5, 2024): I have the same problem (where the layout I want is german, but barrierc switches it to US). But I found a workaround: After barrier has connected, I run `setxkbmap de nodeadkeys` on the client, and then it works as expected. A little bit annoying still, but I can live with it. In case you really need this fixed, try to switch to https://github.com/input-leap/input-leap, which is a fork of barrier that is actually still developed. Don't expect anything to change in barrier, the project seems dead. Last commit is more than 2 years ago.

No labels

Rows
Columns