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

[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 :")

[nbolton]

This issue has been inactive for a while so I'll close it for now.
Please let me know if this is still an issue so that I can reopen it.

[Raniz85]

If no one has actively done anything to fix this, I'm pretty sure it's still an issue

[pruiz]

+1 this was a problem and last time I tried, still was.

…

On Sat, Sep 7, 2024 at 07:09 Raniz Daniel Raneland ***@***.***> wrote: If no one has actively done anything to fix this, I'm pretty sure it's still an issue — Reply to this email directly, view it on GitHub <#4411 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABOV6IARACQ6PQDI426P4DZVKDB7AVCNFSM4A5KPSUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZTGUYDINJZGU3Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nbolton]

Thanks, @Raniz85 and @pruiz for letting me know it's still an issue. What version are you able to reproduce this in today?

[Raniz85]

Server: Linux (Gentoo) 1.14.1-stable
Client: Windows 11 1.14.6-stable

[apro]

1.14-6-stable Rocky 9 and Windows 11 - the same problem wt., 10 wrz 2024 o 07:34 Raniz Daniel Raneland ***@***.***> napisał(a):

…

1.14.1-stable, both on Linux host and Windows client — Reply to this email directly, view it on GitHub <#4411 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB272RJMN4ZWXRUZKXKEFTZV2AGFAVCNFSM4A5KPSUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZTHE3DKOJSGY2Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Pozdrowienia Andrzej Pruski

[nbolton]

@Raniz85 @apro Thanks for the info. Those versions are quite old now. Are either of you able to reproduce this in 1.15 or 1.16? Please let me know if you're a customer or community user so I can point you to the right builds.

[apro]

OK - will try next week (vacations) wt., 10 wrz 2024 o 10:28 Nick Bolton ***@***.***> napisał(a):

…

@Raniz85 <https://github.com/Raniz85> @apro <https://github.com/apro> Thanks for the info. Those versions are quite old now. Are you able to reproduce this in 1.15 or 1.16? — Reply to this email directly, view it on GitHub <#4411 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB272X3BXV22DGUB2WVXP3ZV2UR5AVCNFSM4A5KPSUKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMZUGAYDANJQGY4Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Pozdrowienia Andrzej Pruski

[maribert]

Until recently, I ran the latest version of Synergy 1 (the autoconfiguration feature of version 2 and 3 is not what I want) with the server on Linux and the client on Windows (all with German keyboards). The AltGr bug was very much still in evidence. Then my linux computer croaked, and I temporarily replaced it with a Windows machine. No AltGr bug from Windows to Windows. I am pretty sure that when my new Linux machine arrives, the AltGr bug will be back.