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-gaitzsch]

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

[ghost]

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).

[domalex]

I have been experiencing the same problem with a Swiss German keyboard. The Barrier server works flawlessly from an Arch Linux installation. However, on when using the Barrier client on a Windows 10 machine it would not recognize most keystrokes executed in combination with the AltGr key, such as @ | ¼ ½ ¢ ¬ etc.

A fix would be very much appreciated as this is a critical issue for users who depend on a working AltGr key.

[Cramsarg]

In PuTTY configuration, "Terminal/Keyboard" topics, by default option "Control-Alt is different from AltGr" is checked. Unchecking this option give me back @ | { [ ] } € characters in PuTTY.

There's also a second option "AltGr act as Compose key" I let unchecked.

barrier server : 2.3.2 (Ubuntu 20.10) barrier client : 2.3.3 (Windows 7) KiTTY 0.73.0.1 (PuTTY fork, same options for AltGr as PuTTY ) French keyboard layout.

Hope this may help some of you.

[AdrienGuimbal]

I see a lot of comment about adding

meta = altgr
altgr = shift

in my config file, but how can I do it on Windows 10? In Linux we can use synergy-core --config <filename> but the command isn't available on windows?

[GilDev]

Same issue on macOS 11.1 server and Windows 10 2004 client on Barrier 2.3.3 using the Bépo keyboard layout. No “altgr” setting anywhere in the GUI configurator. Breaking bug that makes me unable to use this software in my case.

[lululock71]

I've got the same issue too... But I kinda solved it by using LCtrl + LAlt instead of AltGr. I know that AltGr is interpreted as LCtrl + LAlt by Windows, but what's weird is that Linux does not react at all when doing this key combo... I guess I'll have to get used to that, it's better than not being able to access those characters.

I don't know what causes this oddity, but note that I've explicitly set the AZERTY keyboard variant for Xorg, which allows me to type characters normally unaccessible with other OSes, such as "É" (CapsLock + 2 (é)) or even "Ù" (CapsLock + ù).

French (AZERTY) layout Server : Arch Linux (xanmod-rt) with Barrier 2.3.3 Client : Windows 10 20H2 with Barrier 2.3.3

[xiduis15]

Same issue on macOS 11.1 server and Windows 10 2004 client on Barrier 2.3.3 using the Bépo keyboard layout. No “altgr” setting anywhere in the GUI configurator. Breaking bug that makes me unable to use this software in my case.

Same issue macOS 11.1 server windows and ubuntu clients.

no altgr available; impossible to do the characters @ and # on a keyboard fr

[matrixes]

I have issues with AltGr as everyone else in this issue.

I'm running

• Lubuntu 18.04 as server
• Windows 10 as client
• Swedish keyboard layout

Using the workaround

meta = altgr
altgr = shift

make most things in Windows accept AltGr+? = \ and AltGr+2 = @.

However,

• it refuses to work well in WSL; forcing me to press AltGr+8 ([) followed by AltGr+2 to get the @ character.
• In vim in WSL I cannot make the @ char appear at all, no matter what combination I use
• `` (backticks/grave accent) and ´ (acute accent) characters do not work at all, which incidentally makes it difficult to type code blocks here without cutting and pasting. :)

[SoftwareSchlosser]

Same for me, can't type characters like {} via AltGr on a german keyboard on a Windows 10 guest connected to a Linux (Ubuntu) host. The workarounds mentioned here didn't work for me.

[kakra]

I have given up on this problem, I'm not even sure if it can be worked around in Windows because many Windows remote control products have similar issues with the AltGr key (even with Windows-to-Windows remoting) or certain keys/characters are not passed down to some types of windows (MSTSC, WSL) - seems to be a problem intrinsic to the Windows input system.

[SoftwareSchlosser]

Maybe one way would be to emulate the AltGr key by sending Ctrl+Alt instead - at least I can type a { by pressing Ctrl+Alr+8. At least it would be nice to have this as an option in Barrier. I already tried to simply do this by using a HotKey but obviously AltGr can't be used as a HotKey either.

[arnholm]

Kubuntu 20.04 as Barrier server Windows 10 as Barrier client Norwegian keyboard

I was hit by this problem as well. This problem made Barrier unusable, since none of @£${[]} could be sent from Server to Client.

The work-around described above that seems to work for me is 1 On the server, save the barrier.conf file 2 On the server, edit barrier.conf and add for the Windows 10 client screen meta = altgr altgr = shift

3. On the server, reload barrier.conf
4. Verify that @£${[]} works on the client

Thanks for maintaining Barrier! Maye this issue can be fixed more permanently, so Barrier is easier to use with non-english keyboards.