Barrier: Cannot type characters that need Alt Gr key

[blizarazu]

Operating Systems

Server: Ubuntu 18.04 (kernel 4.15.0-29-generic)

Client: Windows 10 Home version 1830 (OS compilation 17134.167)

Barrier Version

2.1.0

Steps to reproduce bug

Alt Gr key does not work and characters such as @ { } [ ] # can't be used in the client. For example:

1- Try to write an @ with a Spanish keyboard in the client. You have to press Alt Gr+2.
2- Windows keyboard layout changes to english when you press Alt Gr+2 and a 2 is written instead of @. If Windows is configured only with Spanish keyboard, the language does not change but nothing appears when you press Alt GR + another key.

I also notices that the language switches back to Spanish if you press Shift+3 (this also types a ·).

Other info

• When did the problem start to occur? Always
• Is there a way to work around it? Did not find any
• Does this bug prevent you from using Barrier entirely? No

[maxbla]

Synnergy's old github wiki makes me think your issue was never planned for, as there is no alt gr key listed in their text config guide

shift = {shift|ctrl|alt|meta|super|none}
ctrl = {shift|ctrl|alt|meta|super|none}
alt = {shift|ctrl|alt|meta|super|none}
meta = {shift|ctrl|alt|meta|super|none}
super = {shift|ctrl|alt|meta|super|none}
Map a modifier key pressed on the server's keyboard to a different modifier on this client. This option only has an effect on a client screen; it's accepted and ignored on the server screen.
For instance, you can map the Shift key to Shift (the default), Ctrl, Alt, Meta, Super, or nothing. Normally, you wouldn't remap Shift or Ctrl. You might, however, have an X11 server with Meta bound to the Alt keys. To use this server effectively with a Windows client, which doesn't use Meta but uses Alt extensively, you'll want the Windows client to map Meta to Alt (using meta = alt).

[DuschdrBabbe]

Have the same problem here! Windows7 (Server) Raspi Rasbian (Client)

please fix it :-)

for backslash i use now ALT 92

[BelgarathS]

Hi,
I have the same problem

how would we implement that, it is critical issue for anybody using non-us keyboard.

Best regards
Paul

[BelgarathS]

Hi,
I have identified that altgr is passed as ctrl+alt (this is altgr equivalent for windows but not linux) and that is where the problem begins.
Moreover adding either
shit=altgr
or
alt=altgr
in screen sections (in client config) allow to use those modifier keys to work as proper altgr so it seems more a problem on windows serve side and capturing the original altgr signal rather than alt+control as altgr=anymeta does not work in either client nor server section
moreover alt+ctrl is quite widely used on linux nowadays (f.e workspace manipulation) so even intercepting ctrl+alt and changing it back to altgr seems not to be a proper solution.

[BelgarathS]

as a temporary workaround in ubuntu using gnome-tweaks using
keyboard&mouse/additional layout option/key to choose 3rd level/menu key
allows me to use menu key from windows keyboard as altgr on linux client

[Lucas-M-G]

I have the same Problem with Linux Server, Windows Client and german keyboard.

[BelgarathS]

With windows client you can just add alt=altgr or altgr=alt in your server config in your windowspc: section and that should work

[BelgarathS]

On further investigation, choice of window keymap has tremendous impact on how the keys are being transmitted. I believe we are not capturing the data early enough in the process and the keymap translations are done before we get scan-codes on windows.

[digitizer0]

Have the same issue Linux server, Windows Client

[maxbla]

To whoever tries to squash this bug, this looks suspicious:

bool KeySequence::appendKey(int key, int modifiers)
{
    if (m_Sequence.size() == 4)
        return true;

    switch(key)
    {
        case Qt::Key_AltGr:
            return false;
...

From lines 115-123 of KeySequence.cpp

and I found some documentation (find on page Key_AltGr)

[niikoo]

With synergy server (1.8.7-stable) on UbuntuGnome17.04 and client (1.8.8-stable) on Win10, these lines in synergy.conf seems to have helped me out using the Norwegian keyboard layout incl. the AltGr {[]}@ etc keys on the Win PC:

section: screens
    mywinpc:
        meta = altgr
        altgr = shift
end

This by trial and error. HTH.

This fixes the problem on version 2.2.0-Release-00000000 (October 10, 2018)
Working with Linux (Ubuntu 18.10 with kernel 4.19.5) and Windows 10.

Source

[gerardparareda]

I am having a similar problem but not only with the altgr key, all the symbols are wrong. I've got the same keyboard (client and server) but for example a Shift + 0 is '=' in the server and '_' in the client. These are a qwerty spanish with the middle dot keyboard. Client is running Ubuntu 18.04 LTS and the server Windows 10. Any idea?

[AdrianKoshka]

Perhaps open a new issue @Raxe88?

[gerardparareda]

Sorry about that. For anyone interested I found the solution to my problem on this issue.

[kakra]

This is still a problem with 2.2.0, using a Linux server with a Windows 10 client, and using German keyboard layout. Characters like @, \, or ~ are on the third key level and need AltGr (right Alt-key) to be entered.

My work-around is currently using left Alt+Ctrl (which emulates AltGr in most OSes) to enter these characters but this is very uncomfortable as a German keyboard user.

[digitizer0]

I solved this in config file by setting the following:

section: screens
windowsmachine1:
meta = altgr
altgr = shift
windowsmachine2:
meta = altgr
altgr = shift
end

[marsie321]

This a very old bug. To conclude:

AltGr e.g. for @ at german keyboard is working with Linux-Server and Windows Client partial working:
a) altgr=shift # OK, standalone at win10, but not at WSL bash@win10
b) but not with putty, wsl (Windows Subsystem for Linux) e.g. bash, see attached xev output
c) WORKAROUND: synergy-v1.8.2-stable-36cd521-Windows-x64.msi + # altgr=alt # OK, (win10 + wsl/putty) ... but only synergy <= 1.8.2.

WRONG (from linux server)

KeyRelease event, serial 33, synthetic NO, window 0x380001,
root 0x5a5, subw 0x0, time 3031843, (80,95), root:(398,436),
state 0x8, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

OK (windows clients keyboard)

KeyRelease event, serial 33, synthetic NO, window 0x380001,
root 0x5a5, subw 0x0, time 3110031, (1237,773), root:(1581,1140),
state 0x80, keycode 20 (keysym 0x5c, backslash), same_screen YES,
XLookupString gives 1 bytes: (5c) "\"
XFilterEvent returns: False

[felix-ht]

With synergy server (1.8.7-stable) on UbuntuGnome17.04 and client (1.8.8-stable) on Win10, these lines in synergy.conf seems to have helped me out using the Norwegian keyboard layout incl. the AltGr {[]}@ etc keys on the Win PC:

section: screens
    mywinpc:
        meta = altgr
        altgr = shift
end

This by trial and error. HTH.

This fixes the problem on version 2.2.0-Release-00000000 (October 10, 2018)
Working with Linux (Ubuntu 18.10 with kernel 4.19.5) and Windows 10.

Source

This fixed it for me as well on 2.3.1 Linux server and 2.3.1 Windows Client. Any plans to actually fix this properly?

[spaeps]

I just want let you know that the _Alt-Gr_ key and everyone else works perfectly after client suspension and resume.

I'm just dealing with Linux, since I do not use barrier with anything else.

My setup:
Both Server and Client: Arch Linux with barrier 2.3.1 and Italian layout

For reference, the Italian keyboard layout.

Steps:

• Start Server
• Start Client
• Typing _Alt-Gr+ò_ outputs _2_ (it should print _@_)
• Suspend and resume Client (systemctl suspend)
• Typing _Alt-Gr+ò_ outputs _@_ as expected

Probably something in the resume process _triggers_ the fix but i need to investigate.

I'll let you know.

[BelgarathS]

This is specific windows issue when windows keymap seems to be applied before the keys are intercepted by barrier.Specifically changing keyboard language affects keys that barrier sends across.

[JohanMollevik]

I am also affected, I have a linux server and windows client. When I type AltGr+7 to type a '{' symbol a '[' symbol shows up and the windows client changes keyboard layout from SV to EN. Similar things happens for other symbols.

[nlubisch]

Same problem.

Server: Ubuntu 18.04
Client Windows 10

[DrillSergeant]

Also same problem.

Server: Ubuntu 18.04
Client Windows 10 Pro

[barnaba]

Same problem. ubuntu server 2.3.2 snapshot 9080ce45, client win 10 2.3.2 snapshot 210c2b70)

I've incorporated @niikoo's solution and it seemed to work for most cases. Used it for some time, but finally ran into issues.

While alt+o produces the proper "ó" character in most settings (e.g. notepad) it fails in other. For example in ms word.
What happens when I use alt gr + o on client's physical keyboard: "ó" character
What happens when I use right alt + o on server and it goes through barrier: ms word opens the outlining ribbon

This is quite breaking from my perspective, litearlly can't type in polish with any reasonable speed.

Here's my config:

section: screens
    fasada:
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        switchCorners = none 
        switchCornerSize = 0
    DESKTOP-QA8BAEH:
    meta = altgr
    altgr = shift
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        switchCorners = none +top-left +bottom-left 
        switchCornerSize = 0
end

section: aliases
end

section: links
    fasada:
        right = DESKTOP-QA8BAEH
    DESKTOP-QA8BAEH:
        left = fasada
end

section: options
    relativeMouseMoves = false
    screenSaverSync = true
    win32KeepForeground = false
    clipboardSharing = true
    switchCorners = none 
    switchCornerSize = 0
end

[MPalix86]

Also same problem.

Server: macOS Catalina 10.15.2 (mackbook keyboard)
Client: Kali linux 2019.4 (classic windows pc keyboard)

In addition on mac the alt gr key is not present.

[jemielniak]

Same issue - makes the system not sustainable for users of languages with non-standard characters (mine is Polish).

[wscheicher]

I just observed something strange:
While last week i realized that AltGr wouldn't work (Windows 10 as Server, Debian Buster as Client) and i stumbled over this bug and actually didn't see how this could be solved - strangely the problem vanished without me changing anything.

What i did however: i installed WSL and XcXsrv ... i wonder if that did change something on the Server side ...

[jemielniak]

Thanks! I tried that (I installed WSL and then XcXsrv) and unfortunately it didn't work for me.

[wscheicher]

Update: Looks like it had nothing to do with what i installed on Windows, but rather with my keyboard settings on the linux client. It seems that after having barrierc running, the keyboard layout was not matching the local keyboard, but had a "us" layout - or so. And after several attempts to fix that, and a reboot - some key combinations did work. Not "real" AltGr, but at least @€{}...

I did:
xinput list
setxkbmap -device 5 at # 5 being the ID of my "Virtual core XTEST keyboard"
and then rebooted both PCs

Also messed with dpkg-reconfigure keyboard-configuration and kde keyboard settings, so not 100% sure what actually triggered the change in the behaviour.

[allbombson]

I have a similar issue when using a Japanese keyboard, and multiply keys are passed at times and most the time none are correct.

[allbombson]

I have a similar issue when using a Japanese keyboard, and multiply keys are passed at times and most the time none are correct.

[allbombson]

I have a similar issue when using a Japanese keyboard, and multiply keys are passed at times and most the time none are correct.

[thothothotho]

I have a similar problem with the french bépo layout (https://bepo.fr/wiki/Accueil)
It relies heavily on AltGr, even for pure ascii characters (like {}<>)
setup:
Ubuntu18 (server)
Windows10 (client)

Here is the keys I hit :
AltGr-X

(Here by X, I mean the physical key that is placed at the posiition of the letter X on a us keyboard)
According to the bépo layout, this should generate a {

But I observe a [ being generated instead (and the keyboard indicator on windows 10 switch to EN)

Here are some more examples:

| hit | Expected | Result | remark |
|---|---|---|--|
|AltGr-X | { | [ ||
|AltGr-C | } | ] ||
|AltGr-2 | < | ,||
|AltGr-3 | > | .||
|AltGr-4 | [ | [| correct! |
|AltGr-5 | ] | ]| correct! |
|AltGr-P | & | 7 ||
|AltGr-Q| \| | \ ||

Here is a theory that (partially) explains those results.

The server (ubuntu) sends the KeyCode to the client (windows 10). The client looks up where is that keycode on a US keyboard, then it removes the shift modifier and consider this is the result.

At least there is a strong correlation between Expected and Results. They are always on the same physical key on a us keyboard.

[sgrienen]

I have the same kind of problems, I'm using an Apple keyboard on my MacOS and to control a Win10 PC and Alt-Gr is not working (right Alt key + G should output a @ symbol but I can't get it on Win10 unless I use the left Ctrl+Alt as described by someone in that thread... it's a pain, I wish I could configure it, but I've tried to add
meta = altgr
altgr = shift
in the config file, it doesn't change anything for me.

[aapopajunen]

Having same issues with finnish keyboard layout.
Client: Windows 10
Server: Pop!_OS 20.04 LTS x86_64

[hevi9]

Same issue, finnish keyboard

server: Kubuntu 19.10
client: Windows 10 Pro

[lgallard]

As @digitizer0 pointed out, to workaround this add the following to your screens config:

meta = altgr
altgr = shift

Here you are Screens configuration in Barrier's config file:

section: screens
    curiosity:
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        preserveFocus = false
        switchCorners = none 
        switchCornerSize = 0
        meta = altgr
        altgr = shift
    DESKTOP-HJ8KL6M:
        halfDuplexCapsLock = false
        halfDuplexNumLock = false
        halfDuplexScrollLock = false
        xtestIsXineramaUnaware = false
        preserveFocus = false
        switchCorners = none 
        switchCornerSize = 0
        meta = altgr
        altgr = shift

[1ras]

meta = altgr does nothing at all and altgr = shift is only a partly workaround as some AltGr combinations are still not working, like ~ (AltGr +) and € (AltGr e) on a Germany keyboard.

Also when looking on the actual keys received on the Windows client with this workaround, the key sequence is still wrong. E.g. AltGr + is received as:

VK  SC  Type    Up/Dn   Elapsed Key
-----------------------------------------
A1  136 a   d   0.44    RShift          
A4  038 a   d   0.20    LAlt            
A2  01D a   d   0.00    LControl        
A1  136 a   u   0.00    RShift          
BB  01B a   d   0.00    +               
A2  01D a   u   0.00    LControl        
A4  038 a   u   0.00    LAlt            
A1  136 a   d   0.00    RShift          
BB  01B a   u   0.08    +               
A1  136 a   u   0.03    RShift

Where a locally pressed Altgr + just correctly shows as:

A2  01D     d   0.59    LControl        
A5  138     d   0.02    RAlt            
BB  01B     d   0.17    +               
BB  01B     u   0.11    +               
A2  01D     u   0.01    LControl        
A5  138     u   0.00    RAlt

Traces are done with the Autohotkey KeyHistory command, with the following meaning:
VK=Virtual Key, SC=Scan Code, Elapsed=Seconds since the previous event. Types: h=Hook Hotkey, s=Suppressed (blocked), i=Ignored because it was generated by an AHK script, a=Artificial, #=Disabled via #IfWinActive/Exist, U=Unicode character (SendInput).

Server: Debian 10 with Barrier 2.3.2
Client: Windows 10 with Barrier 2.3.2

[manz4rk]

Server: Windows 10 with Barrier 2.3.3
Client: macOS 10.15 with Barrier 2.3.3

Can't use AltGr because it sends Ctrl+Alt, and in my case (Polish keyboard layout) it does not allow for diacritic characters to be typed. Breaking bug for me, because Right Alt + L is one of the important letters that are often used. Swapping to the nearest key (Meta/Windows) causes Windows 10 to log off (Win + L).