[GH-ISSUE #134] Wrong keyboard layout between Server and Client

gitea-mirror commented

2026-05-05 05:16:51 -06:00

Owner

Originally created by @enricodetoma on GitHub (Sep 22, 2018).
Original GitHub issue: https://github.com/debauchee/barrier/issues/134

Operating Systems

Server: Windows 10

Client: Arch Linux

Barrier Version

2.1.0

Steps to reproduce bug

Set keyboard layout to IT on Server (Windows 10)
Set keyboard layout to IT on Client (Arch Linux)
Bug: barrier reverts to using EN keyboard layout on Client (Arch Linux)

Other info

When did the problem start to occur? Always
Is there a way to work around it? I don't know
Does this bug prevent you from using Barrier entirely? Not entirely but it's very annoying to have the wrong keyboard layout

Originally created by @enricodetoma on GitHub (Sep 22, 2018). Original GitHub issue: https://github.com/debauchee/barrier/issues/134 ### Operating Systems ### Server: Windows 10 Client: Arch Linux ### Barrier Version ### 2.1.0 ### Steps to reproduce bug ### 1. Set keyboard layout to IT on Server (Windows 10) 2. Set keyboard layout to IT on Client (Arch Linux) 3. Bug: barrier reverts to using EN keyboard layout on Client (Arch Linux) ### Other info ### * When did the problem start to occur? Always * Is there a way to work around it? I don't know * Does this bug prevent you from using Barrier entirely? Not entirely but it's very annoying to have the wrong keyboard layout

gitea-mirror added the

bug

label 2026-05-05 05:16:51 -06:00

gitea-mirror commented

2026-05-05 05:16:55 -06:00

Author

Owner

@abrasive commented on GitHub (Oct 16, 2018):

I think this happens because the XTEST extension is used to deliver the keystrokes, and it has its own virtual keyboard. You can see this if you run xinput list:

$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ Broadcom Corp. Bluetooth USB Host Controller	id=11	[slave  pointer  (2)]
⎜   ↳ bcm5974                                 	id=13	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Power Button                            	id=8	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=9	[slave  keyboard (3)]
    ↳ Broadcom Corp. Bluetooth USB Host Controller	id=10	[slave  keyboard (3)]

This can be fixed using setxkbmap -device N where N is the device number from this list.
I have solved this issue for now by putting the following in my .xinitrc:

setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=\([0-9]\+\).\+/\1/'` us colemak

This sets it to layout us, variant colemak. You can work out the correct values for your system, along with any -option settings, by issuing setxkbmap -query.

@abrasive commented on GitHub (Oct 16, 2018): I think this happens because the XTEST extension is used to deliver the keystrokes, and it has its own virtual keyboard. You can see this if you run `xinput list`: ``` $ xinput list ⎡ Virtual core pointer id=2 [master pointer (3)] ⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)] ⎜ ↳ Broadcom Corp. Bluetooth USB Host Controller id=11 [slave pointer (2)] ⎜ ↳ bcm5974 id=13 [slave pointer (2)] ⎣ Virtual core keyboard id=3 [master keyboard (2)] ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)] ↳ Power Button id=6 [slave keyboard (3)] ↳ Video Bus id=7 [slave keyboard (3)] ↳ Power Button id=8 [slave keyboard (3)] ↳ Sleep Button id=9 [slave keyboard (3)] ↳ Broadcom Corp. Bluetooth USB Host Controller id=10 [slave keyboard (3)] ``` This can be fixed using `setxkbmap -device N` where `N` is the device number from this list. I have solved this issue for now by putting the following in my `.xinitrc`: ``` setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=$[0-9]\+$.\+/\1/'` us colemak ``` This sets it to layout us, variant colemak. You can work out the correct values for your system, along with any `-option` settings, by issuing `setxkbmap -query`.

gitea-mirror commented

2026-05-05 05:16:58 -06:00

Author

Owner

@enricodetoma commented on GitHub (Oct 17, 2018):

Really curious: if I use your method with us layout, i.e. with

setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=\([0-9]\+\).\+/\1/'` us

I get correct it layout (except for accented letters, but it is not a problem).
If I set it layout, it is completely wrong.

Anyway thank you very much for this workaround!

@enricodetoma commented on GitHub (Oct 17, 2018): Really curious: if I use your method with `us` layout, i.e. with ``` setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=$[0-9]\+$.\+/\1/'` us ``` I get correct `it` layout (except for accented letters, but it is not a problem). If I set `it` layout, it is completely wrong. Anyway thank you very much for this workaround!

gitea-mirror commented

2026-05-05 05:17:02 -06:00

Author

Owner

@enricodetoma commented on GitHub (Oct 17, 2018):

Now it works with it too, after a reboot...

@enricodetoma commented on GitHub (Oct 17, 2018): Now it works with `it` too, after a reboot...

gitea-mirror commented

2026-05-05 05:17:06 -06:00

Author

Owner

@ARodriguezMX commented on GitHub (Feb 29, 2020):

that is awesome!, a couple of years ago I looking for this solution with no luck. Thanks a lot!

@ARodriguezMX commented on GitHub (Feb 29, 2020): that is awesome!, a couple of years ago I looking for this solution with no luck. Thanks a lot!

gitea-mirror commented

2026-05-05 05:17:09 -06:00

Author

Owner

@rebroad commented on GitHub (Feb 20, 2021):

I don't think this issue should be closed just because some people have found workarounds - this really needs to be something addressed by barrier in a way that most users will be able to configure it - which I would not say applies to the proposed solutions above.

@rebroad commented on GitHub (Feb 20, 2021): I don't think this issue should be closed just because some people have found workarounds - this really needs to be something addressed by barrier in a way that most users will be able to configure it - which I would not say applies to the proposed solutions above.

gitea-mirror commented

2026-05-05 05:17:12 -06:00

Author

Owner

@bplessis commented on GitHub (Mar 15, 2021):

Sadly this hack doesn't work on my issue (french keyboard on linux server & windows client, everything is fine up until i try some AltGr symbols, then the windows switch from FR to "Other Language" and things go awry).

Anyway just wanted to point out that while grep and sed are usefull tool, they are also often not the best ones, xinput is able to select the device to list and natively support reporting only the device id with "--id":
xinput list --id-only "Virtual core XTEST keyboard"

so it then give:

setxkbmap -device `xinput list --id-only "Virtual core XTEST keyboard"` us colemak

@bplessis commented on GitHub (Mar 15, 2021): Sadly this hack doesn't work on my issue (french keyboard on linux server & windows client, everything is fine up until i try some AltGr symbols, then the windows switch from FR to "Other Language" and things go awry). Anyway just wanted to point out that while grep and sed are usefull tool, they are also often not the best ones, xinput is able to select the device to list and natively support reporting only the device id with "--id": `xinput list --id-only "Virtual core XTEST keyboard"` so it then give: ``` setxkbmap -device `xinput list --id-only "Virtual core XTEST keyboard"` us colemak ```

gitea-mirror commented

2026-05-05 05:17:14 -06:00

Author

Owner

@p12tic commented on GitHub (Jun 25, 2021):

I don't think this issue should be closed just because some people have found workarounds - this really needs to be something addressed by barrier in a way that most users will be able to configure it - which I would not say applies to the proposed solutions above.

Agreed, reopening the issue.

@p12tic commented on GitHub (Jun 25, 2021): > I don't think this issue should be closed just because some people have found workarounds - this really needs to be something addressed by barrier in a way that most users will be able to configure it - which I would not say applies to the proposed solutions above. Agreed, reopening the issue.

gitea-mirror commented

2026-05-05 05:17:15 -06:00

Author

Owner

@vanarok commented on GitHub (Jul 11, 2021):

I have two devices with Manjaro installed. The configured keyboard configuration in /etc/X11/xorg. conf. d / 00-keyboard. conf does not apply on the client (two layout languages) for the virtual device described here. I get around this by running the command in the terminal after the barrier client and server connection is established:
setxkbmap -layout us,ru

@vanarok commented on GitHub (Jul 11, 2021): I have two devices with Manjaro installed. The configured keyboard configuration in /etc/X11/xorg. conf. d / 00-keyboard. conf does not apply on the client (two layout languages) for the virtual device described here. I get around this by running the command in the terminal after the barrier client and server connection is established: `setxkbmap -layout us,ru`

gitea-mirror commented

2026-05-05 05:17:17 -06:00

Author

Owner

@mclang commented on GitHub (Sep 10, 2021):

I had this same issue between my two Linux boxes

Server: Manjaro
Client: EndeavourOS
Barrier: v2.3.3-1 (community repo)

Information gathered using xev:

On the Linux server pressing AltGr produced 108 ISO_Level3_Shift, and e.g AltGr+5 gave €.
On the Linux client, using client's keyboard, the result was same.
When using server's keyboard on the client side through Barrier, AltGr produced 92 ISO_Level3_Shift and e.g key combination AltGr+q produced q, not ä as it was supposed to.

For the longest time I tried all the things suggested in the various Windows client issues, but finally the working fix was to run:

$ setxkbmap -device $(xinput list --id-only "Virtual core XTEST keyboard") -layout "us" -variant "altgr-intl"

and restart the client.

Now AltGr still gives 92 ISO_Level3_Shift on the client side. but AltGr+q and AltGr+5 work as they are supposed to.

Maybe this can be fixed in some point, but thanks for the workaround 👍

@mclang commented on GitHub (Sep 10, 2021): I had this same issue between my two Linux boxes **Server:** Manjaro **Client:** EndeavourOS **Barrier:** v2.3.3-1 (community repo) Information gathered using `xev`: - On the Linux **server** pressing `AltGr` produced `108 ISO_Level3_Shift`, and e.g `AltGr+5` gave `€`. - On the Linux **client**, using client's keyboard, the result was same. - When using **server's** keyboard on the **client** side through Barrier, `AltGr` produced `92 ISO_Level3_Shift` and e.g key combination `AltGr+q` produced `q`, not `ä` as it was supposed to. For the longest time I tried all the things suggested in the various Windows client issues, but finally the working fix was to run: ``` $ setxkbmap -device $(xinput list --id-only "Virtual core XTEST keyboard") -layout "us" -variant "altgr-intl" ``` and restart the client. Now `AltGr` still gives `92 ISO_Level3_Shift` on the client side. but `AltGr+q` and `AltGr+5` work as they are supposed to. Maybe this can be fixed in some point, but thanks for the workaround :+1:

gitea-mirror commented

2026-05-05 05:17:18 -06:00

Author

Owner

@stefmanf commented on GitHub (Sep 11, 2021):

Thanks a lot, I had the same problem:

Server: Ubuntu 20.04 on iMac mid 2011
Client: Raspberry pi 4
Barrier: 2.3.3

Keboard layout: Italian (Winkeys)

Now it works fine on the Raspberry.

@stefmanf commented on GitHub (Sep 11, 2021): Thanks a lot, I had the same problem: **Server**: Ubuntu 20.04 on iMac mid 2011 **Client**: Raspberry pi 4 **Barrier**: 2.3.3 **Keboard layout**: Italian (Winkeys) Now it works fine on the Raspberry.

gitea-mirror commented

2026-05-05 05:17:20 -06:00

Author

Owner

@mclang commented on GitHub (Sep 13, 2021):

I tested some more with my Linux server/client setup.

It seems that the keyboard layout Barrier client uses is right from the start:

$ setxkbmap -device $(xinput list --id-only "Virtual core XTEST keyboard") -query
rules:      evdev
model:      pc105
layout:     us
variant:    altgr-intl

but key combinations like AltGr+q still don't work until setting same layout again manually:

$ setxkbmap -device $(xinput list --id-only "Virtual core XTEST keyboard") -layout "us" -variant "altgr-intl"

I hope this helps to figure out the issue.

@mclang commented on GitHub (Sep 13, 2021): I tested some more with my Linux server/client setup. It seems that the keyboard layout Barrier client uses **is right from the start**: ``` $ setxkbmap -device $(xinput list --id-only "Virtual core XTEST keyboard") -query rules: evdev model: pc105 layout: us variant: altgr-intl ``` but key combinations like `AltGr+q` still don't work until setting same layout again manually: ``` $ setxkbmap -device $(xinput list --id-only "Virtual core XTEST keyboard") -layout "us" -variant "altgr-intl" ``` I hope this helps to figure out the issue.

gitea-mirror commented

2026-05-05 05:17:22 -06:00

Author

Owner

@lombad commented on GitHub (Sep 8, 2022):

Manjaro (Server) and Arch Linux (Client) with German (nodeadkeys) layout

Barrier Version: 2.4.0

1) Configuration

I configured both (Server) and (Client) with the same layout for the Virtual core XTEST keyboard.

setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=\([0-9]\+\).\+/\1/'` -layout "de" -variant "nodeadkeys"

2) Restart

Stop and Quit the (Server)
Stop and Quit the (Client)
Reopen Barrier and Start the (Server)
Reopen Barrier and Start the (Client)

🥳 Keystrokes with äöüß work like a charm.

@lombad commented on GitHub (Sep 8, 2022): ## Manjaro (Server) and Arch Linux (Client) with German (nodeadkeys) layout Barrier Version: 2.4.0 ### 1) Configuration I configured both (Server) and (Client) with the same layout for the ` Virtual core XTEST keyboard `. ``` setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=$[0-9]\+$.\+/\1/'` -layout "de" -variant "nodeadkeys" ``` ### 2) Restart - Stop and Quit the (Server) - Stop and Quit the (Client) - Reopen Barrier and Start the (Server) - Reopen Barrier and Start the (Client) :partying_face: Keystrokes with `äöüß` work like a charm.

gitea-mirror commented

2026-05-05 05:17:23 -06:00

Author

Owner

@mclang commented on GitHub (Sep 9, 2022):

Keystrokes with äöüß work like a charm.

Also after client/server computer reboot?

@mclang commented on GitHub (Sep 9, 2022): > Keystrokes with `äöüß` work like a charm. Also after client/server **computer** reboot?

gitea-mirror commented

2026-05-05 05:17:25 -06:00

Author

Owner

@sergiomb2 commented on GitHub (May 9, 2023):

setxkbmap -device xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.+=[0-9]\+.+/\1/'-layout "de" -variant "nodeadkeys"

xinput list | grep "Virtual core XTEST keyboard"
-> Virtual core XTEST keyboard id=5 [slave keyboard (3)]

setxkbmap -device 5 -layout "pt" -variant "nodeadkeys"

fixed my AltGr 7 , 8 , 9 and 0

Thank you

@sergiomb2 commented on GitHub (May 9, 2023): `setxkbmap -device `xinput list | grep "Virtual core XTEST keyboard" | sed -e 's/.\+=$[0-9]\+$.\+/\1/'` -layout "de" -variant "nodeadkeys" ` `xinput list | grep "Virtual core XTEST keyboard" ` -> Virtual core XTEST keyboard id=5 [slave keyboard (3)] `setxkbmap -device 5 -layout "pt" -variant "nodeadkeys" ` fixed my AltGr 7 , 8 , 9 and 0 Thank you

gitea-mirror commented

2026-05-05 05:17:27 -06:00

Author

Owner

@georgehank commented on GitHub (Jul 20, 2023):

Workaround exists… and worked until now. I now have a very crazy keyboard layout. It doesn't even produce an event for all keys. The main keys (letters, digits) are fine (except for being US). But anything else is screwed. I dicked around with setting up barrier as autostart app, but it also get started from the session info, which might or might not be a factor.

Either way, this needs a real fix.

@georgehank commented on GitHub (Jul 20, 2023): Workaround exists… and worked until now. I now have a *very* crazy keyboard layout. It doesn't even produce an event for all keys. The main keys (letters, digits) are fine (except for being US). But anything else is screwed. I dicked around with setting up barrier as autostart app, but it also get started from the session info, which might or might not be a factor. Either way, this needs a *real* fix.

gitea-mirror commented

2026-05-05 05:17:30 -06:00

Author

Owner

@leighss commented on GitHub (Sep 2, 2023):

I had same issue on my RPi 3 Raspbery Pi OS Client with my ArchLabs Lenovo Thinkpad T16 Server
T16 Keyboard is Portuguese
On RPi I had it set to Generic 105 PC, Portuguese, Portuguese via the keyboard preferences on the RPI and some keys were wrong

However when I selected Generic 105 PC (int), Portuguese, Portuguese it all worked!

@leighss commented on GitHub (Sep 2, 2023): I had same issue on my RPi 3 Raspbery Pi OS Client with my ArchLabs Lenovo Thinkpad T16 Server T16 Keyboard is Portuguese On RPi I had it set to Generic 105 PC, Portuguese, Portuguese via the keyboard preferences on the RPI and some keys were wrong However when I selected Generic 105 PC (int), Portuguese, Portuguese it all worked!

gitea-mirror commented

2026-05-05 05:17:33 -06:00

Author

Owner

@sergiomb2 commented on GitHub (Sep 3, 2023):

Hi,

I'm sorry , I think I mixed up things , I was looking for keyboard problems under x11vnc and tigervnc and novnc and I ended up comment here because set "nodeadkeys" on my PT-pt keyboard, solve AltGr 7 , 8 , 9 and 0 problem , I used https://symless.com/synergy but now I use more x2vnc https://github.com/sergiomb2/x2vnc/blob/master/start_x2vnc.txt .

So I did a comment here , and later I saw that set "nodeadkeys" is not a fix, it disable composed keys and is probably a bug in x11vnc. Because only with x11vnc + tigervnc, Altgr doesn't work , if I use just tigervnc and novnc works correctly .

The curiosity is set nodeadkeys at least in my layout keyboard makes some AltGr keys works but have the downgrade of disable composed keys .

I wonder if barrier source code is based on some of these software x11vnc, libvnc (http://libvnc.github.io/ ) , novnc , tigervnc ?

Best regards

@sergiomb2 commented on GitHub (Sep 3, 2023): Hi, I'm sorry , I think I mixed up things , I was looking for keyboard problems under x11vnc and tigervnc and novnc and I ended up comment here because set "nodeadkeys" on my PT-pt keyboard, solve AltGr 7 , 8 , 9 and 0 problem , I used https://symless.com/synergy but now I use more x2vnc https://github.com/sergiomb2/x2vnc/blob/master/start_x2vnc.txt . So I did a comment here , and later I saw that set "nodeadkeys" is not a fix, it disable composed keys and is probably a bug in x11vnc. Because only with x11vnc + tigervnc, Altgr doesn't work , if I use just tigervnc and novnc works correctly . The curiosity is set nodeadkeys at least in my layout keyboard makes some AltGr keys works but have the downgrade of disable composed keys . I wonder if barrier source code is based on some of these software x11vnc, libvnc (http://libvnc.github.io/ ) , novnc , tigervnc ? Best regards

gitea-mirror commented

2026-05-05 05:17:36 -06:00

Author

Owner

@sergiomb2 commented on GitHub (Sep 7, 2023):

BTW , (I hope that is an useful information ) https://github.com/LibVNC/x11vnc/issues/115#issuecomment-1709929660
Running x11vnc with -nomodtweak fix issue for me, on my PT-pt keyboard, AltGr 7, 8, 9 and 0 problems

@sergiomb2 commented on GitHub (Sep 7, 2023): BTW , (I hope that is an useful information ) https://github.com/LibVNC/x11vnc/issues/115#issuecomment-1709929660 Running x11vnc with -nomodtweak fix issue for me, on my PT-pt keyboard, AltGr 7, 8, 9 and 0 problems

gitea-mirror commented

2026-05-05 05:17:39 -06:00

Author

Owner

@aplstroedel commented on GitHub (Apr 13, 2024):

For those who are still looking for a solution to map the right layout on boot, use ~/.xprofile with the following content:

#!/bin/sh

# start barrier in the background, optionally use params
/usr/local/bin/barrier &

# run the setxkbmap command to your needs, using the catchall for belgian layout below:
setxkbmap be

@aplstroedel commented on GitHub (Apr 13, 2024): For those who are still looking for a solution to map the right layout on boot, use ~/.xprofile with the following content: ``` #!/bin/sh # start barrier in the background, optionally use params /usr/local/bin/barrier & # run the setxkbmap command to your needs, using the catchall for belgian layout below: setxkbmap be ```

Rows
Columns

[GH-ISSUE #134] Wrong keyboard layout between Server and Client #107

Operating Systems

Barrier Version

Steps to reproduce bug

Other info

Manjaro (Server) and Arch Linux (Client) with German (nodeadkeys) layout

1) Configuration

2) Restart