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

[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: #6417 #6665

[JMLX42]

Had the same issue with a Windows 10 server and an Ubuntu 20.04 client. Upgrading both to 1.14.0 solved the issue.

[renaudallard]

Had the same issue with a Windows 10 server and an Ubuntu 20.04 client. Upgrading both to 1.14.0 solved the issue.

1.14.0 didn't change anything on my side, alt-gr is still not working properly without a custom configuration file.

[bjoernmartin]

I tried what @renaudallard suggested but it did not work. Also using Linux server and Windows client, version 1.14.0-stable on both.

I played around a bit and found out that I can map the alt-gr key to other keys like shift, so the Linux server seems to "send" the key stroke of the alt-gr key to Windows. But I cannot map anything (I tried alt or meta) to alt-gr on the Windows side. Whenever I do that, pressing the key on the Linux side has no effect anymore on the Windows side.

Hope this helps.

[BentHaase]

Another 6 months has gone by, autumn has fallen here in the northern hemisphere and this issues sadly is still not fixed with the latest release 1.14.1.32-stable.

Is this issue even still being worked on or can this be closed as WONTFIX?

[jowilkes]

I'm pretty sure this would be the #1 bug if users could vote on bugs here.

[LeadManPL]

@jowilkes : there is customary way of voting here: just give a "thumb up" to initial post in this issue (~18 thumbs ATM)

[booooza]

On Swiss keyboard (Logitech MX Keys) with Linux as server and macOS as client I'm happy with:

section: screens
	linux:
		meta = altgr
	mac:
		altgr = alt
		ctrl = super
end

Feels hacky though..

[BentHaase]

On Swiss keyboard (Logitech MX Keys) with Linux as server and macOS as client I'm happy with:

section: screens
	linux:
		meta = altgr
	mac:
		altgr = alt
		ctrl = super
end

Feels hacky though..

Yup, and it does only partially work for most symbols. Some special symbols like single upper quotes do not work at all.

[TacoByte]

Same issue, Mac server (Italian logitech keyboard) and Debian client.

I can't even select altgr in the modifier keys in the settings because altgr is nowhere to be found. i only have shift, ctrol, alt, meta, and super

I just bought Pro, only to discover synergy is pretty much useless! I can't type any special characters, the whole thing is pretty much broken, what's the point? And this hasn't been fixed in years?

[TacoByte]

I have managed to find a workaround that is easy, quick, and works for me (Debian 10 client).

I am simply remapping my Level 3 modifier (which is what ALT GR is supposed to do) in xkb.

note: This only seems to work if I keep en as the default keyboard language, and I have my actual regional keyboard as my secondary keyboard language, which is what I select (for example, mine is it). So make sure your setup is similar

In /usr/share/X11/xkb/symbols, open level3

Each block is a different mapping and contains the line xkb_symbols "name_of_the_mapping"

Choose the mapping that you prefer.

For example, i just set both my ALT keys to act as ALT GR, so the name of that mapping is alt_switch

There is a bunch of premade settings, for example to use your ENTER key you can use enter_switch, so scroll through and find something that works for you.

Now, in the same folder, find the file with the country code of your keyboard. Mine is it.

Find the block relevant to your setup. I am just using the default symbols, so the very first block (that starts with default partial alphanumeric keys) is the one I am editing.

At the very bottom of the block, I find the line include "level3(ralt_switch)"

ralt_switch is the mapping that doesn't work for us since right ALT aka ALT GR key presses are not communicated properly.

So we are going to edit that line to point to the alternative mapping that we picked in step 1.

That line for me becomes include "level3(alt_switch)"

Save and log out. Log back into your user account. (Remember to set your keyboard to your country code!)

Finally, you can access all the special characters on your keyboard.

There are probably more elegant ways to achieve this but I hope this helps other people while we wait for this bug to get fixed.

[Raniz85]

Looking into this a bit it seems that on my setup (Linux Server, Windows Client) AltGr produces the ISO_LEVEL_3_SHIFT keycode which doesn't seem to exist in Windows, causing the keystroke to be dropped.

If I open up KDE keyboard settings and tick Alt and Meta are on Alt under Alt and Win behaviour AltGr produces ALT_R which when sent to Windows works as expected.

This, however, means that I can no longer use AltGr-modified keys on Linux.

So we need some way of translating ISO_LEVEL_3_SHIFT into ALT_R when send from Linux to Windows.

[Raniz85]

After further digging it seems that

altgr = alt

Correctly makes Synergy translate AltGr (key code 0xEF7E) into Right ALT (keycode 0xEFEA).

However, when AltGr is working on Linux it does not send AltGr + unmodified key, but rather the modified key directly, which Windows doesn't seem to understand, which is why it's only working for some keys.

For example, when I turn on Alt and Meta are on Alt, and press AltGr + 2 Synergy sends the keycodes for ALT_R and 2. Whereas when I have it turned off it sends the keycodes for ALT_R and @.

This seems to confuse Windows, I'm guessing it tries to interpret ALT_R + @ into some sort of shortcut, fails and just discards it.

Setting

altgr = none

makes all my special characters show up in Windows correctty.

[Raniz85]

The above is working for me in Windows, but if I start a VMWare Horizon Client to administrate a server it gets borked again.

I think to really solve this Synergy needs to send the unmodified keys that are pressed instead of the modifier and the modified keys (i.e. ALT_R + 2 instead of ALT_R + @)

[Raniz85]

This SO thread might contain the solution:
https://stackoverflow.com/questions/48098629/how-to-get-virtual-key-codes-from-keypress-and-keyrelease-events-in-x11-with-mod

[raikoug]

After further digging it seems that

altgr = alt

Correctly makes Synergy translate AltGr (key code 0xEF7E) into Right ALT (keycode 0xEFEA).

However, when AltGr is working on Linux it does not send AltGr + unmodified key, but rather the modified key directly, which Windows doesn't seem to understand, which is why it's only working for some keys.

For example, when I turn on Alt and Meta are on Alt, and press AltGr + 2 Synergy sends the keycodes for ALT_R and 2. Whereas when I have it turned off it sends the keycodes for ALT_R and @.

This seems to confuse Windows, I'm guessing it tries to interpret ALT_R + @ into some sort of shortcut, fails and just discards it.

Setting

altgr = none

makes all my special characters show up in Windows correctty.

this worked for a normal Linux as server (pop_os with IT_it) and Windows 10 as client (IT_it)

[danterpaniagua]

After further digging it seems that

altgr = alt

Correctly makes Synergy translate AltGr (key code 0xEF7E) into Right ALT (keycode 0xEFEA).

However, when AltGr is working on Linux it does not send AltGr + unmodified key, but rather the modified key directly, which Windows doesn't seem to understand, which is why it's only working for some keys.

For example, when I turn on Alt and Meta are on Alt, and press AltGr + 2 Synergy sends the keycodes for ALT_R and 2. Whereas when I have it turned off it sends the keycodes for ALT_R and @.

This seems to confuse Windows, I'm guessing it tries to interpret ALT_R + @ into some sort of shortcut, fails and just discards it.

Setting

altgr = none

makes all my special characters show up in Windows correctty.

Genius! This helped me a lot!!!!
Thankyou!!!! [ ][ ][ ][ ] (From windows client)

[DanielLaberge]

None of the config workarounds work me. Has anyone ever made this work with this setup?

Server: macOS 12.4
Client: Windows 10 Pro 21H2
Keyboard layout on both machines: fr-CA

[CeilidhAN]

I am also encountering this issue
Server: Manjaro Linux Kernel 6.0.8-1-MANJARO
Client: Windows 11 Pro 21H2
Keyoard Layout for both systems: en-DE

[desymless]

I am also encountering this issue Server: Manjaro Linux Kernel 6.0.8-1-MANJARO Client: Windows 11 Pro 21H2 Keyoard Layout for both systems: en-DE

Did the workaround not work in your setup?

altgr = none

or

altgr = alt

[CeilidhAN]

It works for some keys, but not altgr+q for @

On Mon 21. Nov 2022 at 15:58 Daniel Evenson ***@***.***> wrote: I am also encountering this issue Server: Manjaro Linux Kernel 6.0.8-1-MANJARO Client: Windows 11 Pro 21H2 Keyoard Layout for both systems: en-DE Did the workaround not work in your setup? altgr = none or altgr = alt — Reply to this email directly, view it on GitHub <#4411 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALPBM4JR7YLFHIKNF4L6EYDWJOEY5ANCNFSM4A5KPSUA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Thank you, Cèilidh Nevling, MIS Founder PartyCat Productions, LLC Business Contact ***@***.***>

[FuriousMalky]

After further digging it seems that

altgr = alt

Correctly makes Synergy translate AltGr (key code 0xEF7E) into Right ALT (keycode 0xEFEA).

However, when AltGr is working on Linux it does not send AltGr + unmodified key, but rather the modified key directly, which Windows doesn't seem to understand, which is why it's only working for some keys.

For example, when I turn on Alt and Meta are on Alt, and press AltGr + 2 Synergy sends the keycodes for ALT_R and 2. Whereas when I have it turned off it sends the keycodes for ALT_R and @.

This seems to confuse Windows, I'm guessing it tries to interpret ALT_R + @ into some sort of shortcut, fails and just discards it.

Setting

altgr = none

makes all my special characters show up in Windows correctty.
OMG YES !!
This helped for PL lang. Linus mint as server and win10 as client - seems all symbols are sent correctly now - thank you :")