Synergy-core: AltGr not sent to client from server

[nbolton]

I'm pretty sure that the AltGr support has been lost on every OS (actually I can't remember if we ever supported it). This issue is to consolidate all issues into one.

3327, #3929, #4339, #3476, #582, #1832, #1849, #2163, #1850

[lusor]

AltGr works in current version (1.7.3) with Linux (debian testing) as server and Windows (Windows 7) as client with the following config (copy&paste from #3327):

section: screens
linux:
windows:
altgr = alt
end

[Fire-Dragon-DoL]

I'm on OSX 10.10 and Windows 7, I tested the workaround but it doesn't behave properly.

OSX server, Windows 7 client I can get everything right, but altgr either doesn't get sent or behaves like ALT with the workaround. But on Windows 7, altgr = Alt + Ctrl, so it's not behaving as it should, at all.

I know it may not look like important for people with US keyboard, but with italian layout, you type { with ctrl + alt + shift + è, so it's easier to type shift+altgr+è, and for [ i just press altgr+è. Same issue with ` which I type using altgr+'

Being a software developer, those characters are quite important for me

[msak]

altgr = alt is not working for Mac clients if the server is a Win 7 with 1.7.3.

[friesoft]

AltGr wasn't working ootb for me on Fedora 22 as Server and Windows 7 as Client using Synergy 1.7.3.

Using the config posted above for the windows client (altgr = alt) works for me.

[Fire-Dragon-DoL]

@friesoft when you say "it works", do you mean that altgr get properly sent as "ctrl+alt" on windows or is it sent as alt only?

[anders-sjoegren]

The workaround works for me; Lubuntu 14.10 server and Windows 7 client. Synergy 1.7.4.

[rasmuskl]

Still seeing this in 1.7.4.

Server: Windows 10
Client: OSX 10.10
Keyboard layout: Danish

My AltGr key on the Windows is sent to the Mac as Ctrl+Alt (verified by checking out other combinations using the left side Ctrl and Alt keys). Unfortunately, on the Mac all of the combinations that I use AltGr for on Windows only use Alt on Mac - and doesn't work with Ctrl.

The workarounds on this issue seem to be for Windows clients, but the other way around it doesn't work.

[joachimtingvold]

I get the behaviour in #3476. More specifically it happens on all modifier keys, so the client only gets Shift_L, Ctrl_L, Alt_L and Windows_L.

Server: OSX 10.10.5
Client: Debian Jessie
Keyboard layout (on server): Norwegian
Keyboard layout (on client): Norwegian
Keyboard: Apple USB fullsize (with numpad).

Confirmed that the server sees left + right, but the client only receives left for both.

[erdnussflips]

Still not working with registered 1.7.5 and german keyboard

Server: Windows 10 1511 x64
Client: Mac OSX 10.11.2

None of the workarounds works for me.

Alt+Ctrl (Alt+Cmd) is still send to client.

[lorenzochomp]

I'm also suffering this issue, using Synergy 1.7.5 on a MacMini (Server) and a Unbuntu Linux box (client). I've added the line "altgr = alt" line to my client's screen in the server's config file, but still doesn't work :(

Has anybody found a solution for non-Windows clients?

[chrisjrob]

In 1.7.5 the above workaround does not appear to work for:

• _Server:_ Windows 8.1 Professional 64
• _Client:_ Ubuntu 14.04

Control L is sent to client.

By trial and error I found that by adding a reversed alt = altgr to the client screen settings (in the server configuration) seemed to work - insofar as running xev on the client and typing ALTGR showed that ISO_Level3_Shift was appearing.

Unfortunately this seemed to disable the Alt key on the client and I still could not get the Compose Key working, which was what I was trying to accomplish.

If anyone has found a working workaround for a Windows server and Linux client I would be pleased to hear it!

[yuppity]

In the Swedish keyboard layout {, }, [, ], @, and others are accessed with Alt Gr. Typing these characters on Windows from OS X server seems to be impossible without adopting a new keyboard layout.

Either this should get fixed very soon or the user should be warned before purchasing.

[robinhuse]

In the Swedish keyboard layout {, }, [, ], @, and others are accessed with Alt Gr. Typing these characters on Windows from OS X server seems to be impossible without adopting a new keyboard layout.
Either this should get fixed very soon or the user should be warned before purchasing.

I bought the software a few hours ago, having the same problems.

[mrauter]

same problem here... so it's not useful for me...
linux server, mac client

:(

[cgonzal]

Same issue. Mac OS El Capitan server, Ubuntu 16.04 LTS client, both with UK keyboards. All the right hand modifiers (ctrl, alt, supr, shift) get mapped on client to the left modifiers, this makes synergy pretty much unusable. And is kind of a bummer.

[bitkill]

This makes my mac keyboard (portuguese layout) useless in a programming (windows) environment. Please find a way to support altgr. Mac server & windows client.

[sfeigl]

The most annoying bug in Synergy...

On German keyboard, backslash is on Alt Gr + ß (who needs backslash?)

Hope this gets fixed soon.

[JoakimSoderberg]

This is a huge issue on Swedish keyboard layout. I have Windows 10 server towards OSX 10.11.1 ...

For example to type { used about every 3 seconds when programming you press: AltGr+7 on Windows. This should be translated to alt+shift+8 on the OSX computer. Or the correct character should be produced at least (not sure how that works in Synergy exactly).

An alternative to pressing AltGr on the Swedish layout is to press ctrl+alt as well.

I am pretty sure this used to work before?

[Hubro]

Ok, seriously... I'm using a Windows 10 desktop as my server and a Linux (Debian) laptop as my client. I'm supposed to code on the Linux laptop, but how am I supposed to do that without the Alt Gr key? There's no way. There are also NO workarounds that work. It appears to be no keystrokes that produce the @ symbol, for example. How is this seemingly simple bug still a problem, when it makes the software COMPLETELY useless for a large number of people?

This bug was opened and assigned the "priority-soon" label in March 2015. Get your priorities straight and fix this bug.

[Hubro]

I just noticed something strange. I switched to a different layout using setxkbd -layout us, then switched back to my normal layout (setxkbd -layout no) and now AltGr works for writing characters such as @, {, [ etc. This definitely did _not_ work before I switched layouts, as AltGr+2 produced the number 2 rather than @.

It still registers as Control_L when using xev though.

[monkeyPy]

I guess I have found a workaround that works at least for me.
Server is running on MacOS and my client is a Windows 10. On this Windows machine I also ran a VirtualBox instance providing an Ubuntu 14.04.
Cause of the AltGr key is not send correctly I use AutoHotKey as a free tool on Windows for remapping all important keys.

If someone is interested in thats my synergy.ahk script

Alt::RAlt
!5::[
!6::]
!8::{
!9::}
!n::~
!7::|

Cause Synergy does not send the adjusted key strokes to my virtualized Ubuntu I need to run a second tool AutoKey there which also works fine.

I agree that this workaround is not the most prettiest one but after all these years after buying synergy and not being able to use it I am kind of happy.

[esanumIT]

Well, up until 1.8.2, the altgr = alt in the config for the windows client (server is a unix, mint 17) worked. Now, that is broken too ... :/
EDIT: Now == 1.8.3-rc1

[nathan818fr]

Confirmed. Since 1.8.3 the "altgr = alt" don't work anymore. :/
Can you check this long time issue @nlyan ?

Edit: On the french keyboard layout, Alt-Gr is required for: # @ [ ] { } | \ ^ ~`
So that's just horrible (for hashtag, email and coding).

[Fire-Dragon-DoL]

Is this really not priority-urgent yet? Now it's not even possible to use altgr=alt...

[christofchen]

I am on 1.8.3, and also "altgr=alt" does not work anymore. But pressing left ctrl + left-alt on the server (linux) seems to be translated into altgr on the client (win7).

[nlyan]

@nathan818fr I would guess that this is a regression caused by the fix for #2765 . @XinyuHou did most of the work on that, so I will ask him for an opinion on this when he's next available

[nathan818fr]

Great !
And confirm that ctrl + left-alt (on server, debian) work like alt-gr (on client, win 10).

[cgonzal]

This seems to be the case for MacOS 10.11 as server and Ubuntu client, both running 1.8.3, altGr gets translated into alt, and seems to be the same for all the modifier keys on the right side of the keyboard (alt, super) get mapped into the left.

[jimyx17]

I can confirm altgr is still not working and that, for me, the ctr+left-alt is not working for '{' and '}'

Sorry, forgot to say Synergy 1.8.3 with Spanish ISO keymap on both server and client. Server Ubuntu 16.04, client Windows 10.

[cgonzal]

This is still an issue on 1.8.4, MacOS 10.11 as server and Ubuntu client, both running 1.8.3, altGr gets translated into alt, and seems to be the same for all the modifier keys on the right side of the keyboard (alt, super) get mapped into the left.

[timitt]

I wrote new solution to forums, but let's share it here too.
Write
altgr=shift
to configuration instead of old altgr=alt. Worked for me at least.

And seriously make this highest priority issue. Without working altgr you lose quite a few European customers.

[T3rminat0r]

@timitt thanks for that, that fixes altgr at least (server linux mint, client win 10). Super/WinKey is still not being transfered correctly for me, though. :-1:

[timitt]

I also use Linux Mint as server and Win10 as client. For me Super and WinKey works (not sure what kind of issues you have). I don't have any tricks for those in conf-file.

[jimyx17]

@timitt Thanks for the trick. Now I can stop using the fucking US keymap in my spanish keyboard.

I really love to be able to use a single keyboard for the different machines I handle but really, without algr is close to impossible to write a single line of code.

I don't understand how is possible that this is still not at top of the priority bug list.

@T3rminat0r I'm using an ubuntu server, win 10 client and I can use super and winkey no problems whatsoever

[XinyuHou]

@csantorum
Could you give us a bit more explanations? Are you using Apple keyboard? With Apple keyboard, the Altgr key is a combination of Ctrl + Alt.

Could you also give me some test cases, including what language input and what character you are expecting?

https://support.apple.com/en-gb/HT202676

[cgonzal]

Hi, I'm using an Apple keyboard, both systems are in English. There are a few keys that are mapped off. The |\ key by the return gets mapped to the ~ by Z, which is where it is on a PC keyboard (this happens even when selecting a Mac keymap in the client machine), the 2 key, that also contains the @ is different too.

[XinyuHou]

@csantorum
That sounds like a keyboard layout mismatch problem. Please have a look at this ticket #4280.

What is your use case of AltGr key?

[JoakimSoderberg]

@XinyuHou At least on Swedish keyboard layout AltGr is used to get a \ and many characters like that, especially ones used when programming. So this bug makes synergy pretty much useless for such use cases.

This is a HUGE issue that needs proper attention.

I use a OSX client, with a Windows Server... Both use Swedish keyboard layout. This used to work fine with earlier versions.

[XinyuHou]

@JoakimSoderberg
Thanks for the information.

Could you open keyboard viewer on your Mac and use your server AltGr key to see what keys are simulated on your client side?

[JoakimSoderberg]

Ok, I'm at work now so cannot check my setup but will do that when I get home tonight or tomorrow.

[JoakimSoderberg]

@XinyuHou Ok, I'm looking now... Pressing AltGr on my Windows computer (Host) while the keyboard viewer is open on OSX shows me that it emulates pressing Ctrl+Alt correctly.

However, when I press any other button... for instance AltGr+7 which would produce \... It looks as if Ctrl+Alt are released, 7 pressed, and then Ctrl+Alt are pressed again (the keys flicker really fast).

Compared to doing this natively on the OSX this does not happen.

So it seems the issue is not that pressing AltGr is not working properly in itself. But rather pressing it in combination with any other keys.

[XinyuHou]

@rasmuskl
Which version of Synergy are you using? I have tested with Windows 10 server and a Mac 10.12 client, both use Danish keyboard input. Pressing AltGr works the same as pressing Alt on Mac.

Could you give us a bit more information?

[XinyuHou]

@JoakimSoderberg

Swedish keyboard layout

could you give us some more information. I set my Windows and Mac to use Swedish keyboard layout, It's AltGr + - to produce \

When add the keyboard layout on my Windows, there are two, one for Finland and the other one is Sverige. Which one are you using?

On Mac, there are 3 options, Swedish, Swedish+Pro and Swedish Sami+PC.

[rasmuskl]

@XinyuHou I was using 1.7.4 as mentioned in my comment.

It's been more than a year though, and I haven't used Synergy in the meantime. I don't even have a Mac anymore :-)

[XinyuHou]

@JoakimSoderberg
Sorry if I ask this before, what version of Synergy are you using?

[philomatic]

Also having problems with this:

Server: Raspberry Pi
Client: Win10 64 Bit

Synergy version:
synergy-master-stable-6a7703f (from November 6, 2016 19:37; on both client / server)

I recently reinstalled / updated my client version, and before that the altgr = alt worked nicely for me as workaround
(with version synergy-master-beta-2ed3d26 on server, don't know client version anymore)

But now only altgr = shift seems to do the trick.
While this works for "normal" desktop applications (Explorer, Chrome, etc.), it doesn't for terminals (tested Git Bash and Putty).

I can however tell the terminals to use Ctrl + LeftAlt as AltGr, but that's an unhappy workaround, as its profile specific in putty and not the default option.
(Whenever I create a new profile (or its automatically created by WinSCP) for one of my remote clients, I need to reconfigure that).

Please fix this one, it's old enough now!

PS: Writing as a pro user with recently bought pro support, I want my 8 bucks to make it count! ;)

[JoakimSoderberg]

@XinyuHou sorry for the late reply. I upgraded to 1.8.5-stable-a18eba7 and still have the issues.

Server: Windows 10 64-bit, Swedish keyboard layout - 1.8.5-stable-a18eba7
Client: OSX El Capitan 10.11.1, Swedish keyboard layout - 1.8.5-stable-a18eba7

Turns out I had forgotten to update the OSX version from 1.7.6, so this works for me now.

Looks like it is sending alt+2 as expected now to make @ for example...

could you give us some more information. I set my Windows and Mac to use Swedish keyboard layout, It's AltGr + - to produce \

Yea I miss-stated sorry, altgr+(key 2 left from backspace)

When add the keyboard layout on my Windows, there are two, one for Finland and the other one is Sverige. Which one are you using?

Swedish (Svenska Sverige)

On Mac, there are 3 options, Swedish, Swedish+Pro and Swedish Sami+PC.

Swedish Pro

(Now reinstalling these versions I also ran into https://github.com/symless/synergy/issues/4251 which is very annoying)

[geeheim]

I upgraded from 1.8.2 to 1.8.5 (Server: CentOS 7, Client: Windows 7).

In version 1.8.2 the workaround from posting 2 (altgr = alt) works. With version 1.8.5 (same configuration) it is not working.

I downgraded to 1.8.2, again.

[argonius2412]

I am on 1.8.5 on MacOS 10.12.1 (Server)
My client is xubuntu with also 1.8.5 of synergy.

I tried altgr = alt and altgr = shift but nothing worked.

My keyboard layout is DE and on Mac i run Apple USB Keyboard.

Please provide a solution, how to use AltGR on Linux Client systems as I am unable to do the | - Symbol :/

[argonius2412]

update: got it working: used my apple "cmd" key (formerly known as apple-button) as altgr.

I configured in the server the client by double clicking on it, selected in keymapping the super key to map to alt. Then saved the configuration and edited with editor and replaced
super = alt
by
super = altgr

reloaded and it worked :)

[mathvdh]

Guys I have the same issue with Synergy server running on a mac and the client running on windows.

Its IMPOSSIBLE to code with my keyboard layout in this conditions.

I am a pro-paid users.

How can we fix this ? I'm a developer, maybe I can help buy giving you all necessary tests and imputs to fix it ?

What I can tell you already is that whatever I do, I tried all the "fixes" above. I observe that when I type altgr on the mac it sends alt on the windows machine .. ???

The fix from argonius above doesnt work for me super = altgr ??

[argonius2412]

Hi Mathieu

Sorry, I don’t have a AltGR on my default Mac Keyboard, so that’s why i use the Super Key (CMD) to emulate AltGr

Am 01.12.2016 um 01:09 schrieb Mathieu Van der Haegen [e-mail]:

Guys I have the same issue with Synergy server running on a mac and the client running on windows.

Its IMPOSSIBLE to code with my keyboard layout in this conditions.

I am a pro-paid users.

How can we fix this ? I'm a developer, maybe I can help buy giving you all necessary tests and imputs to fix it ?

What I can tell you already is that whatever I do, I tried all the "fixes" above. I observe that when I type altgr on the mac it sends alt on the windows machine .. ???

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/symless/synergy/issues/4411#issuecomment-264037939, or mute the thread https://github.com/notifications/unsubscribe-auth/ARV_joFSrO9OVu-ZWOfmeXiAwPtmbQMWks5rDhBLgaJpZM4Dqnyo.

[mathvdh]

Hi argonius I would be happy to use the CMD key instead of the altgr key but it doesn't seem to work for me...

[argonius2412]

which version do you run?

have you adjusted the key mapping for the client in the server config?

Am 01.12.2016 um 09:59 schrieb Mathieu Van der Haegen [e-mail]:

Hi argonius I would be happy to use the CMD key instead of the altgr key but it doesn't seem to work for me...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/symless/synergy/issues/4411#issuecomment-264117026, or mute the thread https://github.com/notifications/unsubscribe-auth/ARV_jplriZ0fFEpgcpDdtKkOuhKoUP2Zks5rDoxXgaJpZM4Dqnyo.

[mathvdh]

I'm running version 1.8.5-stable-a18eba7.
I tried the config as you stated but it doesn't work for me for some reason.
Anyway, nevermind I found another solution using a different approach:
I remapped in ubuntu the alt key to altgr using xmodmap.

Create a .Xmodmap file if you dont have one with this content :

! Swap Mod1 and Mod5
!
remove Mod1 = Alt_L Meta_L Alt_L Meta_L
remove Mod5 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
keysym Alt_L Meta_L Alt_L Meta_L = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
keysym ISO_Level3_Shift NoSymbol ISO_Level3_Shift = Alt_L Meta_L Alt_L Meta_L
add Mod1 = Alt_L Meta_L
add Mod5 = ISO_Level3_Shift

Then run in a console : xmodmap .Xmodmap
You can also add xmodmap ~/.Xmodmap to .xinitrc file if you want it to be done at every reboot.

Cheers

[argonius2412]

why ubuntu?

i thought you running macOS server and windows 10 client?

i didn’t ran any xmodmap stuff… i only adjusted the config on server side.
can you paste your server config? then i can compare

Am 01.12.2016 um 10:34 schrieb Mathieu Van der Haegen [e-mail]:

I'm running version 1.8.5-stable-a18eba7.
I tried the config as you stated but it doesn't work for me for some reason.
Anyway, nevermind I found another solution using a different approach:
I remapped in ubuntu the alt key to altgr using xmodmap.

Create a .Xmodmap file if you dont have one with this content :

! Swap Mod1 and Mod5
!
remove Mod1 = Alt_L Meta_L Alt_L Meta_L
remove Mod5 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
keysym Alt_L Meta_L Alt_L Meta_L = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
keysym ISO_Level3_Shift NoSymbol ISO_Level3_Shift = Alt_L Meta_L Alt_L Meta_L
add Mod1 = Alt_L Meta_L
add Mod5 = ISO_Level3_Shift

Then run in a console : xmodmap .Xmodmap
You can also add xmodmap ~/.Xmodmap to .xinitrc file if you want it to be done at every reboot.

Cheers

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/symless/synergy/issues/4411#issuecomment-264124407, or mute the thread https://github.com/notifications/unsubscribe-auth/ARV_jvuC0kwUrxb4QvGveadUbP9WAYeVks5rDpSKgaJpZM4Dqnyo.

[mathvdh]

So Its a bit complicated, I agree.
I'm running macOS server and Win 10 client, true but I'm developing on ubuntu in virtualbox (not my choice, its for work) on Win10 .. And the altgr doest work either on Win10 or inside the Ubuntu VM)
I tried your fix in the client section : super = altgr
But it doesnt do anything for me ...
I can copy my config but I removed the fix since it doesnt work ...

[maartendemunck]

In my configuration (Debian testing server, Windows 10 client and a Belgian AZERTY keyboard), the "altgr=alt" configuration option works with version 1.8.3. With 1.8.5, both "altgr=shift" and "altgr=none" work to get the special characters (|, @, #, ^, {, }, [, ], ', `, \, ~, €) on the Windows client, but I'm currently unable to get these characters inside a (XUbuntu) virtual machine using VirtualBox on the Windows client.

Using xev in the Ubuntu VM on the Windows client, "altgr=shift" causes the AltGr key to act as a "Shift_R" key; "altgr=none" gives no reaction on the AltGr key, but AltGr + another key causes a Ctrl_L press, Alt_L press, key press (sometimes the key I pressed, sometimes another key), key release, Alt_L release, Ctrl_L release.

[2075]

this ticket is open since early 2015. will you ever fix this?

[christofchen]

Just another datapoint for version 1.8.6:
Server Win10 / Client Linux (Ubuntu 16.04), both german keyboards.
Out-of-the-box "usual" problems with "no altgr" or wrong keymappings on the client.

It immediately starts working without any configuration change to synergy as soon as one issues a "setxkbdmap de" before starting the "synergyc --enable-crypto ..."

-> altgr works, all symbols work, diacritics work.

I autostart the client now with a small shellscript "startsynergy":

!/bin/bash

killall synergyc
setxkbmap de
synergyc --enable-crypto 192.168.20.161

[antekone]

Something is clearly wrong here.

Synergy server: synergys 1.8.7, protocol version 1.6
Synergy server running on ArchLinux.

Synergy client 1: Windows 10

• Polish national letters (łóżźćęśńąŁÓŻŹĆĘŚŃĄ) work only when there is 'altgr = shift' declaration in the config file. This is clearly wrong. With this line, both Left Alt and Right Alt produce valid polish letters. Without this line, there is no polish letter support for neither Left Alt, nor Right Alt.

Synergy client 2: macOS Sierra

• Polish national lettes (same as above) work when there is 'altgr = alt' definition in the config file. However, hitting the ralt+l combination produces letter Ļ -- it's not a polish letter (it should produce lowercase ł). Hitting shift+ralt+l produces uppercase Ł - that's correct. Now most interesting part: hitting caps lock, and hitting shift+ralt+l correctly produces lowercase ł. This is clearly wrong. Left alt works correctly for all letters.

[Catscrash]

for me (ubuntu server, win7 client) the solution by @tperalta82 in this issue: https://github.com/symless/synergy/issues/5723 works finally perfectly

[tatouft]

I had the same problem. The synergy server is Win10, the client CentOS7. Synergy 1.8.7 and both keyboard are Belgian.
Reading all your comments, I just tried to change the keyword layout on CentOS and it worked. I found a alternate Belgian layout which works with AltGr.

[mixu-]

Please fix this... Synergy has had this issue for years and for me it makes the difference between "Crap. Can't use" and "Great". I paid money for it too.

[goeddea]

The "altgr=shift" workaround functions for me with an Ubuntu (16.04) server and Windows 10 client.

However, this should not be necessary. I just bought a license, installed and this was a showstopping issue that I found within minutes. Fix this!

[maartendemunck]

@goeddea For me, the "altgr=shift" doesn't always work in MS Office (e.g. to get a @ or \ in a Word document) and never works in my VirtualBox VMs (which I use for development). Debian testing server and Windows 10 client.

[mcolak]

I have a same problem. Alt-gr not working I use ubuntu mac.

[maribert]

The altgr = shift workaround mitigates the problem for me (Ubuntu Zesty server, Windows 7 and 10 clients, German keyboards all around). It is now working _almost_ everywhere, the notable exceptions being PuTTY -- if I open a remote session to a UNIX computer in PuTTY running on either of the Windows clients, I cannot type AltGr special characters into it, which is kind of annoying as the pipe (|) and backslash () characters are among the ones that I cannot use. (I have to resort to reaching over to the Windows system's own keyboards, which sucks.)
Practically everyone in the world, with the exception of a few if rather widespread keyboard layouts, will need AltGr support working, preferably without having to fiddle with the configuration.
Fix this!

[T3rminat0r]

@XinyuHou ... you circle-duplicate-closed those 4 tickets? ... which is the issue that still tracks this bug? (as it isn't fixed, yet...)

[drando]

Hello. I've just bought synergy to share a keyboard between two kubuntu machines, and the bug is there. Those 2 are kubuntu 17.04, with a spanish keyboard. Cannot use "@" con the client computer because altgr+2 doesn't work.

Do you know a workaround for that case?

Thank you very much!

[ArneNorbit]

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.

[Tayfur-zz]

I use Synergy Version 1.8.8 on Ubuntu 16 (Server) and in Windows (client) I use version 1.7.6 and the workaround (adding altgr = alt) still works.

Did you guys ensured that Synergy is using the correct synergy configuration file?
To do that, simply fo to File->Save configuration as...
and save the configuration file whereever you want. Then edit the file as discussed above.
Afterwards you have to tell Synergy that it should use the saved and edited configuration file by clicking "Use existing configuration" and browsing to the file you just saved.

[maartendemunck]

@Tayfur That (or some other variant, depending on your version or combination of versions) works in most applications on the Windows client for me, but not in Microsoft Word (and probably the other Office applications) nor in a Linux virtual machine in VirtualBox on the Windows client (which I use for C++ development).

[zimonth]

Synergys server v1.7.6 in Linux (Fedora) and Synergyc client v1.8.8 in Windows 10.

Same problem here. AltGr is not sent as Alt+Ctrl, so I coudln't type eg. *@,[],{},* characters. Finding this thread made me figure out I need to press Alt+CTRL to get those. So AltGr keyboard-button is not sent as Ctrl+Alt through synergy. The keyboard works fine in Linux and also if I straight connect this to Windows 10 machine.

I was wondering if in Windows' c:/Users/[username]/Documents/synergy.conf I could enforce something like:

section: screens
    ....
    windowspc:
          altgr = alt+ctrl
end

[stenis999]

@zimonth The comment from @ArneNorbit (3 comments above yours) worked perfectly for me. I'm using synergy server 1.8.8 on Ubuntu 16.04 and synergy client 1.8.8 on windows 10. The config change was on the server side.

[Gerporgl]

The suggestion

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

almost worked for me but I also had to put it in the server section as well:

section: screens
    myubuntu1604pc:
        meta = altgr
        altgr = shift
    mywin10pc:
        meta = altgr
        altgr = shift
end

otherwise the altgr+@ would not work (but the altgr+\ would work for some reason)

I am using a Canadian French keyboard character configuration.
Synergy 1.8.8 stable on Ubuntu 16.04 and 1.8.8 stable on Windows 10.

[speleo3]

where do I put altgr = shift in Synergy 2.0? I tried editing /var/lib/synergy/synergy.conf but it's automatically overwritten when starting synergy-service.

(Server: Arch Linux, KDE, German keyboard; Client: macOS 10.12)

[chrisjrob]

Updated to 2.0.7 and still not working. I would love to have the use of my Compose key again, been without it for so many years now.

(Server: Windows 10 Pro 64-bit; Client: Ubuntu 16.04)

[Ukko-Ylijumala]

Synergy 2.0.10. altgr + @ \ € not working for me either with stock settings. Ubuntu 16.04 host, virtualized Windows 8.1 client, both with Finnish keyboard layout. (left) ctrl+alt does work in stead of alt+gr, but an official fix would be good.

[poromaa]

Roundup 2-3 years since this thread is started. no solution.
Of course I didnt know about this before i bought it two days ago.

running 1.9-1-stable
OSX: server
Win10: client

If monitoring keypress from sharpkeys in win10 every key is registered as a left-key (ctrl shift etc)
this simply makes it impossible to remap anything i guess.

Managed to rebuild keyboard layout in windows with Keyboard Layout Creator 1.4 (now working in win10) but limits changes of alt,shift and ctrl, thus not possible to remap alt to altgr from that.

Is it possible to use conf-file on the 2.0 version as well? Tried the 2-version but it seems symless is focusing on some other user than me in this version.

Who is this software made for? I guess there are quite many developers here (biased since we are here, anyway).
Has anyone tried ShareMouse with any more success?
Cheers

[LeadManPL]

@poromaa : luckily for me I knew about that, an few other bugs, which some of them I reported myself (many not on github, but via email) and I see that many other bugs reported are still open for many years. That is why I am waiting with paying for Synergy 2 until they are fixed. At least partially.
Previous model with 1.x series was better, because it allowed me to test software and I bought licences for 1.x.

[mixu-]

I confirm @christofchen 's method solves this issue.

1. Start synergy
2. Run on the problematic Linux client:
   setxkbmap fi -option grp:alt_shift_toggle

Voilá, @{[]} work as expected!
I'm on Synergy 1.9.1 with Windows 10 as server and Debian 9 as client.

[poromaa]

@mixu- this does not work if client is Window.
My setup
Server: macOs 10.13.6
Client: win10

Is there any solution when server is macOS and client is Windows10?
The problem
Synergy cannot in any way send right-alt or right-ctrl or right-anything, whereas there is no way to remap that alt-gr key that on the client side will get detected as a simple left-alt key.
I have actually tried to remap server to send non_us_backspace as left-alt to be able to re-map it on client (windows), but this seems to be impossible due to some restriction in key-board layout remapping tools. Can't simply remap a §-letter to a alt-gr key.

My "workaround"
Best solution so far as for my knowledge and hours of research I have put into this:
do nothing with the config.
Relearn how to type by using ctrl+alt (left or right :) + any special character.
Make sure to remember how to use altgr, since this old behaviour will still be only way on your macOs-computer.

[tperalta82]

although I haven't used synergy for ages, there was a similar bug where I found a fix
https://github.com/symless/synergy-core/issues/5723#issuecomment-261753394

Try it

[poromaa]

Thanks @tperalta82, but I have tried that and all combinations of that that I could come up with. Seems osx-version is not working same way as linux does. Thanks anyway.
By the way: im using synergy 1.9.1-stable-2a0225c1

[poromaa]

Does anyone know if this has been solved?
I don't dare to upgrade from 1.9.1 to 1.10

[feload]

@poromaa The problem still exists in v1.10.1, I tried with a macOS 10.13.6 server and a windows 10 client.

[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 for me.

[Zitrax]

@niikoo that one works for me too with Linux / Windows and Swedish layout.

[AlexClander]

Having same issue, spanish keyboard layout, windows 10 server and ubuntu 16.04 client. I am not able to use any ALTGR combination. Tried multiple solutions mentioned on this thread and none fixed it.

Server: Windows 10 - Synergy version : 1.10.1-stable-8941241e
Client: Ubuntu 16.04 - Synergy version: 1.6.2
Keyboard layout: Spanish

ALT Gr + Numbers keyroad Combinations on terminal:

1 = \
2 = Nothing
3 = Nothing
4 = Nothing
5 = €
6 = ¬
7 = Undo?? (It seems to bind to undo)
8 = Redo??  (It seems to bind to redo)
9 = Arg 9
0 = Arg 0
' = Nothing
¡ = Arg 1

Nothing = Doesn't display anything when typing or seem to make any action.

2. setxkbmap fi -option grp:alt_shift_toggle

Not working for me on Windows 10 as server and Ubuntu 16.04 as client.

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 for me.

Tried this on ubuntu client and not working, where can you find config file for Windows 10 server? Only found synergy.conf under OpenSSL

[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

[seteq]

I just can't believe that this absolutely annoying bug has not been fixed in 4+ years now.

I'm using CentOS 7 as server and Windows 10 as Client - both with german keyboard layout and all updated.
AltGr is still not working ootb as supposed in the latest Synergy 1.10.2 release.

[zimonth]

The fixes provided above do not work for me either. It may work for awhile, but then after some time, maybe after LockScreen, or switching between screens/monitors or something, it fails to work and cannot be reset without fully restarting.

[Meloman-zz]

Hi,
I have Ubuntu 19.04 running 1.10.3-stable-ca35737a as server and 2 clients running the same version on Win10 (VM with VGA Passthrough and Laptop).
It won't work either solutions you provided (QWERTZ with Swiss french mapping).

The only workaround is to use "ctrl + alt" on Windows clients to get @ or #

[piotrek-szczygiel]

It's already been more than 5 years.
It's blocking a lot of people from properly working using this product.
Is anyone working on this issue?
If not, are there any plans to fix it?

[Aymkdn]

My workaround was to use another similar app: https://www.inputdirector.com/

[A-riex]

Got this to work on my setup by adding the line (alt = altgr) to the config file.

Swedish Keyboard Layout
Server: Windows 10
Client: Raspbian

Save the config file to your computer and edit it in notepad. Then tick the "Use existing configuration" in Synergy, and select your config file (e.g. "setup.sgc").
You might have to manually change the file into a .sgc

section: screens
Raspi:
halfDuplexCapsLock = false
halfDuplexNumLock = false
halfDuplexScrollLock = false
xtestIsXineramaUnaware = false
switchCorners = none
switchCornerSize = 0
alt = altgr

[ericdescabanes]

I just spent hours trying to get this to work. Comments on this issue helped. Hope this can help others.

I use Barrier, not Synergy. Barrier is derived from Synergy and it has the exact same problem and i suspect everything below also applies to Synergy.

My setup:

• Server: Linux Ubuntu 20.04 running snap barrier 2.3.2-snapshot-9080ce45
• Client: Windows 10 running barrier 2.3.2-snapshot-210c2b70
• Keyboard: Swiss (French)

On Ubuntu, i run a snap installation of barrier.

The user decides in the main window of barrier which computer is server and which is/are client.

The configuration file only applies to the server, not the client. The config file can be selected in the main window. If you're trying to set the config file from the command line when starting barrier, you can view the log (menu Barrier > Show Log) to see which config file is actually loaded. I suspect that the place to store the config file for it to be loaded automatically in a snap installation on Ubuntu would be somewhere in $HOME/snap/barrier/...

As indicated by many others, i created a config file (menu Barrier > Save Configuration), and then added the 4 lines to that file:

section: screens
    my_Windows_10_PC:
        [...]
        meta = altgr
        altgr = shift
    my_Ubuntu_20_04_PC:
        [...]
        meta = altgr
        altgr = shift
end

With the Swiss keyboard, the "@" is entered as AltGr-2. I use this for all my tests.

The config file above solves the issue of the AltGr key not working on the client PC, for some applications. It works with Firefox and the Windows cmd shell. It does not work in MS Word nor in the Windows Subsystem for Linux (WSL). In Word, AltGr-2 acts as a dead key; followed by SPACE i get the degree character '°'. In WSL, AltGr-2 causes a bell sound; hitting it twice produces a list which i don't recognize:

::1                            my_Windows_10_PC               ip6-localnet
fe00::0                        my_Windows_10_PC.my_domain     ip6-loopback
ff00::0                        ip6-allnodes                   ip6-mcastprefix
ff02::1                        ip6-allrouters                 localhost
ff02::2                        ip6-localhost

My PC name and domain are edited for privacy. Typing CTRL-ALT-2 does about the same thing.

At one point in my tests, typing AltGr-2 would change the keyboard setting on Windows from "ENG SF" (English using a Swiss french keyboard) to "ENG US" (English using a US keyboard). I have both options enabled on my Windows 10 laptop because i have used a US keyboard at times in the past. I assume that Windows sees an unknown key sequence in ENG SF and switches keyboard settings automatically.

Other attempt: without AltGr

I also tried something completely different: producing an "@" character without the AltGr on my Ubuntu PC. My keyboard on Ubuntu is configured to output 4 different characters on the 2 key: 2, " (Shift-2), @ (AltGr-2), ⅛ (Shift-AltGr-2). I added a 5th output when in Caps-Lock mode: @. This way, i can also produce the @ by typing 2 when CAPS LOCK is on. That was fairly easy to do; i'll explain below. But the result is exactly the same as editing the Barrier config file above: i can use the caps lock to type an @ in Firefox and cmd, not in Word and WSL. If anyone can explain this behavior, i'd be interested to hear about it.

To reproduce what i did on Linux (see also link):

Dump keyboard configuration:    xkbcomp $DISPLAY output.xkb
Keep it for reference:      cp output.xkb keymap.xkb
Edit the new file:      see diff below
Use the new file:       xkbcomp keymap.xkb $DISPLAY

Here are the edits i made: diff output.xkb keymap.xkb

<         type[group1]= "FOUR_LEVEL",
<         symbols[Group1]= [               2,        quotedbl,              at,       oneeighth ],
---
>         type[group1]= "FOUR_LEVEL_PLUS_LOCK",
>         symbols[Group1]= [               2,        quotedbl,              at,       oneeighth,    at ],

The group1 refers to the configuration for the Swiss keyboard.
The "FOUR_LEVEL_PLUS_LOCK" xkb type already existed in the dump. Just in case, it's definition is:

    type "FOUR_LEVEL_PLUS_LOCK" {
        modifiers= Shift+Lock+LevelThree;   // this type of key uses 3 modifier keys
        map[Shift]= Level2;
        map[LevelThree]= Level3;        // LevelThree is the name of the AltGr key in this file
        map[Shift+LevelThree]= Level4;
        map[Lock]= Level5;          // Lock means "when Caps Lock is active"
        map[Shift+Lock]= Level2;
        map[Lock+LevelThree]= Level3;
        map[Shift+Lock+LevelThree]= Level4;
        level_name[Level1]= "Base";
        level_name[Level2]= "Shift";
        level_name[Level3]= "Alt Base";
        level_name[Level4]= "Shift Alt";
        level_name[Level5]= "Lock";
    };

I added the comments above. Not sure about the comment character.
Note that 3 modifier keys, each pressed or not, means there are 2^3 = 8 combinations. The code above defines 7 of those 8 combos in the map[] (i.e. all but the no-modifiers combo) and maps it to 5 levels. The level names correspond to the order the symbols[] is defined.

[acidbourbon]

Hi. Of course I have the same problem as you all. I am using a German keyboard and have to use AltGr +Q to write an @.

My set-up: Linux Mint 19 as Synergy Host, Windows 10 as Synergy Client.

I got pretty good results by remapping AltGr to Shift in the synergy config and remapping RightShift back to AltGr back on Windows 10 with a separate little open source tool called "SharpKeys".

Since Synergy sends a LeftShift when I press on either physical shift key, the remapping does not "cost" you any keys.

Find a step-by-step HOWTO on my blog: https://acidbourbon.wordpress.com/2020/08/10/altgr-trouble-with-synergy-a-workaround/

[BentHaase]

Are there any plans to fix this issue after 5.5 years?
Surely there are workarounds which 'might' work but as a paying customer I expect this to work. This renders the application basically useless for certain regions as one cannot type an @ or other important characters on the client.

[andreacndn]

The issue has slowly but steadily moved its way up on our development backlog.
We are currently wrapping up the release of 1.13, and we plan to include issue #4411 and other related ones in the next release.

[LeadManPL]

Happy to hear that! And happy that Synergy team started to respond to github issues questions

[renaudallard]

I must admit that this is a very annoying issue. @ being probably the most common character you cannot send, but there are a lot of others which are useful too.

[acidbourbon]

This seems like the discussion is gaining some momentum again. Yes please fix the @ issue! It is crucial for basically ALL non-US keyboard users! It makes THE difference!

[joyrider3774]

hope it gets fixed soon as i'm having the same problem with a windows server and linux client

[renaudallard]

The issue has slowly but steadily moved its way up on our development backlog.
We are currently wrapping up the release of 1.13, and we plan to include issue #4411 and other related ones in the next release.

It seems, it's still not working on 1.13 without a manual config file.

[toussa]

The issue has slowly but steadily moved its way up on our development backlog.
We are currently wrapping up the release of 1.13, and we plan to include issue #4411 and other related ones in the next release.

It seems, it's still not working on 1.13 without a manual config file.

and the manual config does not work for everybody... I still have the issue with a linux server and a windows client. It's a big drawback since I am a software developer and use a lot of {[]}`@\| chars

[renaudallard]

This works for me for a debian 10 server and a windows 10 machine, but it's far from ideal

in section: screens
linux:
meta = altgr
altgr = shift
windows:
meta = altgr
altgr = shift

[BentHaase]

This works for me for a debian 10 server and a windows 10 machine, but it's far from ideal

in section: screens
linux:
meta = altgr
altgr = shift
windows:
meta = altgr
altgr = shift

This works!

Make sure to select Use existing configuration in Synergy's interaface and select your configuration file which you edited.
For me it's /home/<username>/.synergy.conf.

[matrixes]

My situation is much like many of yours and specifically almost to the letter the same as @ericdescabanes

Adding my comment here in the hopes that more work is put on fixing this issue.

[jose1711]

Related: https://github.com/symless/synergy-core/issues/6417 https://github.com/symless/synergy-core/issues/6665