search

debauchee / barrier

Open-source KVM software
Other
27.7k stars 1.52k forks source link

Wrong keyboard layout between Server and Client #134

Open enricodetoma opened 6 years ago

enricodetoma commented 6 years ago

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

abrasive commented 6 years ago

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 commented 6 years ago

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 6 years ago

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

ARodriguezMX commented 4 years ago

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

rebroad commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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:

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:

stefmanf commented 3 years ago

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 commented 3 years ago

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 commented 2 years ago

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

:partying_face: Keystrokes with äöüß work like a charm.

mclang commented 2 years ago

Keystrokes with äöüß work like a charm.

Also after client/server computer reboot?

sergiomb2 commented 1 year ago

setxkbmap -devicexinput 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 1 year ago

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

aplstroedel commented 7 months ago

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