github-starred/barrier

Fork 0

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

[GH-ISSUE #437] Client keyboard layout is used instead of host one #337

New issue

Open

opened 2026-05-05 06:03:50 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 06:03:50 -06:00

Owner

Originally created by @mirh on GitHub (Sep 15, 2019).
Original GitHub issue: https://github.com/debauchee/barrier/issues/437

Operating Systems

Server: Windows 7

Client: Manjaro Linux

Barrier Version

2.31 git/snapshot

Steps to reproduce bug

Have some random keyboard layout (italian in my case)
Write from the keyboard on the host to the client

Other info

Not sure if this couldn't have something to do with #45

Originally created by @mirh on GitHub (Sep 15, 2019). Original GitHub issue: https://github.com/debauchee/barrier/issues/437 ### Operating Systems ### Server: Windows 7 Client: Manjaro Linux ### Barrier Version ### 2.31 git/snapshot ### Steps to reproduce bug ### 1. Have some random keyboard layout (italian in my case) 2. Write from the keyboard on the host to the client ### Other info ### Not sure if this couldn't have something to do with #45

gitea-mirror commented

2026-05-05 06:03:54 -06:00

Author

Owner

@mirh commented on GitHub (Sep 15, 2019):

I found out
setxkbmap $(setxkbmap -query | grep "^layout:" | awk -F ": *" '{print $2}')
fixed it.
It'd be nice if this wasn't needed on every reboot though, I guess?

@mirh commented on GitHub (Sep 15, 2019): I [found out](https://wiki.archlinux.org/index.php/Synergy#Keyboard_mapping) `setxkbmap $(setxkbmap -query | grep "^layout:" | awk -F ": *" '{print $2}')` fixed it. It'd be nice if this wasn't needed on every reboot though, I guess?

gitea-mirror commented

2026-05-05 06:03:55 -06:00

Author

Owner

@mirh commented on GitHub (Sep 18, 2019):

Ok I understood more the culprit.
On linux (that is, my client) I had set my keyboard layout to it, us (that is: two in order of preference).
Somehow barrier is always using the last one.

Which seems actually wrong on two levels
a) the preference is obviously from the one with more priority to the lower
b) shouldn't the thing be using my host settings to begin with?

@mirh commented on GitHub (Sep 18, 2019): Ok I understood more the culprit. On linux (that is, my client) I had set my keyboard layout to `it, us` (that is: two in order of preference). Somehow barrier is always using the last one. Which seems actually wrong on two levels a) the preference is obviously from the one with more priority to the lower b) shouldn't the thing be using my ***host*** settings to begin with?

gitea-mirror commented

2026-05-05 06:03:57 -06:00

Author

Owner

@AdrianKoshka commented on GitHub (Sep 19, 2019):

shouldn't the thing be using my host settings to begin with?

One would assume so.

@AdrianKoshka commented on GitHub (Sep 19, 2019): > shouldn't the thing be using my host settings to begin with? One would assume so.

gitea-mirror commented

2026-05-05 06:04:01 -06:00

Author

Owner

@eNTi commented on GitHub (Oct 9, 2019):

Hi. Having the exact same issue. Server: Windows 10, Client: Artix Linux.

It's always using the default us layout instad of my preferred one. It's also ignoring any settings I've put into my Xorg config, so my CAPSLOCK key doesn't work as Meta4 which makes things a lot more complicated for me.

@eNTi commented on GitHub (Oct 9, 2019): Hi. Having the exact same issue. Server: Windows 10, Client: Artix Linux. It's always using the default us layout instad of my preferred one. It's also ignoring any settings I've put into my Xorg config, so my CAPSLOCK key doesn't work as Meta4 which makes things a lot more complicated for me.

gitea-mirror commented

2026-05-05 06:04:03 -06:00

Author

Owner

@mirh commented on GitHub (Oct 9, 2019):

Ok, I'm pretty dumb.
I also experienced similar breakages after just having added a third layout (no barrier involved at all!)
And it just turns out that if you don't have the keyboard widget "making sure you are actually using the right one" in the windows, the autoselection shenanigans in the DE might go nuts.

Because the xkbmap list isn't possibly even about preferences.. It's most essentially an unordered set of available choices.

I guess like the transition/hook/switch barrier does, somehow, someway, whatevs, triggered the same "innocent" behaviors.
So at the end of the day, it's quite a simpler problem to fix.

Even though, now I'm wondering a) if you should take into account that host and clients could have different layout "lists" b) how you could even override one with the other
EDIT: turns out en-us really get the preferential treatment #1298

@mirh commented on GitHub (Oct 9, 2019): Ok, I'm pretty dumb. I also experienced similar breakages after just having added a third layout (no barrier involved at all!) And it just turns out that if you don't have the [keyboard widget](http://linuxblog.darkduck.com/2013/11/how-to-configure-keyboard-layouts-in-xfce-cinnamon-mate.html) "making sure you are actually using the right one" in the windows, the autoselection shenanigans in the DE might go nuts. Because the xkbmap list isn't possibly even about preferences.. It's most essentially an unordered set of available choices. *I guess like* the transition/hook/switch barrier does, somehow, someway, whatevs, triggered the same "innocent" behaviors. So at the end of the day, it's quite a simpler problem to fix. Even though, now I'm wondering a) if you should take into account that host and clients could have different layout "lists" b) how you could even override one with the other EDIT: turns out en-us really get the preferential treatment #1298

No labels

Rows
Columns