Wrong keyboard layout between Server and Client

[enricodetoma]

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

[abrasive]

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.

[enricodetoma]

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]

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

[ARodriguezMX]

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

[rebroad]

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.

[bplessis]

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

[p12tic]

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.

[vanarok]

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

[mclang]

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 👍

[stefmanf]

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.

[mclang]

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.

[lombad]

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.

[mclang]

Keystrokes with äöüß work like a charm.

Also after client/server computer reboot?

[sergiomb2]

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

[georgehank]

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.

[leighss]

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!

[sergiomb2]

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]

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

[aplstroedel]

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