Different keyboard layouts causes key mismatch

[davidstosik]

Hello, following #5, I'm opening a detailed issue, including a description of my setup, and layouts for client and server. As, to me, the problem seems to be that the Mac client assumes server keyboard has the same layout, I named the issue accordingly. Feel free to tell me if it's not good enough.

I'll post very shortly an extensive list of how keys currently map. In the meantime, here's a reminder of my setup.

Server:

• Thinkpad X1 Carbon (new version) with standard US QWERTY keyboard
• Main keyboard is on USB: Ducky Shine3 with Japanese JIS layout (Let's try to forget this line for now, and focus on the laptop's keyboard.)
• Ubuntu 14.04
• Synergy 1.6.2 (latest release to date)

Client:

• MacBook Pro 15", mid 2010, with Apple's French AZERTY layout
• OS X Yosemite 10.10.1
• Synergy 1.6.2 (latest release to date)

Here's a link to my original comment.

Obviously, I'm willing to help on my free time, so if you ever have a patch you want me to test, feel free to ask.

[davidstosik]

First experiment: unplug all external keyboards, and set both laptops in configuration above so that their respective attached keyboard works as expected (Synergy isn't involved yet). That means my Ubuntu OS is setup to use a very standard English(US) layout, whereas my Mac OS is set to use Apple's French AZERTY layout (note: it's different from standard French AZERTY layouts).

Then I set up Synergy as described above, for both server and client, move my mouse to the client to get focus, then start typing on the server's keyboard.

Here is, side-by-side, the characters I am expecting (from the key pressed server side), and the character I actually get (on the client's screen).

# *Expected*            *Result*

 `1234567890 -=       `&é”’(§è!çà -=    # <== the result on this line is very close to the MacBook Pro's physical layout.
  qwertyuiop []\       qwertyuiop ():
  asdfghjkl ;'         asdfghjkl ;’
  zxcvbnm ,./          zxcvbnm ,;:

# When Shift key (on the server side) is pressed:

 ~!@#$%^&*() _+       N8##*%¨1*5° _+
  QWERTYUIOP {}|       QWERTYUIOP 5°L
  ASDFGHJKL :"         ASDFGHJKL /3
  ZXCVBNM <>?          ZXCVBNM >>?

Notice how it goes crazy on the bottom right side.

In following test, I switched MacOS X's "input source" setup to "U.S". (Expectation is the same, so I just pasted the result output below).

\ 1234567890 =/
  azertyuiop 5-.
  qsdfghjkl ,4
  wxcvbn; m,.

#Shift:

N *±±}”{ !}%_ +?
  AZERTYUIOP %_L
  QSDFGHJKL >#
  WXCVBN: ~~M

Crazy too, right?

To the layman that I am, it looks like Synergy server grabs a very low-level keycode when a key is pressed, sends it to the client that then just simulates a key press on the same key code, without even checking if the hardware layouts match.

[davidstosik]

Experiment #2, with only one slight change: server runs on the same hardware, but on Windows 8.1 64bits. The results are exactly the same as the ones shown above.

[davidstosik]

Experiments #3 and #4: reproduce #1 and #2 above by swapping client and server roles, still on the exact same hardware.

#3 Server on Mac OS X, client on Ubuntu 14.4:

#  *Expected*          *Result*

 @ &é”’(§è!çà )-     [ ^∅@&*o∅!,∅ (-
   azertyuiop ^$       azertyuiop =$
   qsdfghjklm ù`       qsdfghjklm ∅{
 < wxcvbn ,;:=       < wxcvbn ,;'_

# Shift:

 # 1234567890 °_     # 1234567890 §∅
   AZERTYUIOP ¨*       AZERTYUIOP ∅"
   QSDFGHJKLM %£       QSDFGHJKLM %£
 > WXCVBN ?./+       > WXCVBN ?./:

I used the "empty set" Unicode symbol ∅ to symbolize outputs that didn't show any character on the client's screen. Hopefully you'll either see it, or the usual square.

#4 Server on Mac OS X, client on Windows 8.1:

This last one works quite well, surprisingly (I mean, regarding precedent results). There's only one thing that doesn't work, but it feels like it could have its own, separate issue: on Apple's French AZERTY layout, many common characters are accessible with a combination that includes Alt. For example, to get curly brackets {}, I'll use Alt+( and Alt+), for the vertical bar (pipe) |, I'll use Shift+Alt+l (the last one is a downcase L), backslash \ will be Shift+Alt+: (which makes sense because Shift+: is /). None of these characters went through to the Windows client.

[nbolton]

@dstosik Thanks for contribution. Your results and observations are extensive! This should help us to diagnose the issue.

[macgeneral]

Hi,

I got the same Issue here, Server iMac, Client Macbook Pro, both got DVORAK - QWERTY as keyboard layout. The Hardware Layout is QWERTZ (german) on both machines.

When pressing a key on the iMac it gets mangled around and DVORAK gets applied twice (like pressing L on the hardware keyboard should result in an N with DVORAK, but instead B is the result. (which would be correct if I had pressed N on the hardware keyboard). => the keyboard layout get's applied "twice" because Synergy sends the resulting key to the MacBook Pro instead of the hardware key.

Workaround for me: set the iMac Layout to german, then at least the MacBook produces the DVORAK layout I expect (but it confuses me on the iMac a little even if I can use both layouts with 10 fingers :)) or set the layout on the Client (MacBook to QWERTZ (german)), then both Macs use DVORAK (because it only get's applied once) as long as I don't switch to the MacBooks internal keyboard, but then the QWERTY part of the layout (DVORAK QWERTY uses Dvorak for all keys unless you use the command key - which helps when using short cuts because you don't have to "relearn" them for DVORAK (CMD + C is CMD + C on the real keyboard instead of CMD + I which it would be with the DVORAK layout).

I don't know if it's possible to send the "real key pressed" to the client so it can apply it's own layout. But I hope there's a way to fix it!

[adeadman]

I'm also experiencing this bug, but interestingly with two identical keyboard layouts. Windows 7 server with Japanese keyboard layout, 2006 MacBook Pro also with Japanese keyboard layout. Both OS languages are set to English, with the Japanese IME enabled on both.

Server	Client
1234567890-^\	1234567890-6]
qwertyuiop@[	qwertyuiop2@
asdfghjkl;:]	asdfghjkl;;[
zxcvbnm,./\	zxcvbnm,./]
Caps:
!"#$%&'()=~|	!#$%')0 ~~}
QWERTYUIOP{ | QWERTYUIOP~
ASDFGHJKL+*}	ASDFGHJKL~({
ZXCVBNM<>?_	ZXCVBNM<>?=

[despairblue]

Same problem here using US layout on both (the linux server and the mac client). Every key that the native

This happens when I enter = (outputs 0 on the macbook)

Server

2015-02-08T20:03:31 DEBUG1: new mask: 0x0000
    /build/synergy/src/synergy-1.6.2/src/lib/synergy/KeyState.cpp,426
2015-02-08T20:03:31 DEBUG1: event: KeyPress code=21, state=0x0000
    /build/synergy/src/synergy-1.6.2/src/lib/platform/XWindowsScreen.cpp,1456
2015-02-08T20:03:31 DEBUG1: onKeyDown id=61 mask=0x0000 button=0x0015
    /build/synergy/src/synergy-1.6.2/src/lib/server/Server.cpp,1595
2015-02-08T20:03:31 DEBUG1: send key down to "Beuths-MacBook-Air.local" id=61, mask=0x0000, button=0x0015
    /build/synergy/src/synergy-1.6.2/src/lib/server/ClientProxy1_1.cpp,44
2015-02-08T20:03:31 DEBUG1: new mask: 0x0000
    /build/synergy/src/synergy-1.6.2/src/lib/synergy/KeyState.cpp,426
2015-02-08T20:03:31 DEBUG1: event: KeyRelease code=21, state=0x0000
    /build/synergy/src/synergy-1.6.2/src/lib/platform/XWindowsScreen.cpp,1513
2015-02-08T20:03:31 DEBUG1: onKeyUp id=61 mask=0x0000 button=0x0015
    /build/synergy/src/synergy-1.6.2/src/lib/server/Server.cpp,1622
2015-02-08T20:03:31 DEBUG1: send key up to "Beuths-MacBook-Air.local" id=61, mask=0x0000, button=0x0015
    /build/synergy/src/synergy-1.6.2/src/lib/server/ClientProxy1_1.cpp,59

Client

DEBUG1: recv key up id=0x0000003d, mask=0x0000, button=0x0015
DEBUG1: keystrokes:
DEBUG1:   button=0x001e virtualKey=0x001d keyDown=up client=0x0000
DEBUG1: recv key down id=0x0000003d, mask=0x0000, button=0x0015
DEBUG1: mapKey 003d (61) with mask 0000, start state: 0000
DEBUG1: find best:  0000 0000
DEBUG1: best key index 0 of 3 (exact)
DEBUG1: found key in group 0
DEBUG1: state: 0000,0000,0000
DEBUG1: flip: 0000 (0000 vs 0000 in 0000 - 0000)
DEBUG1: desired state: 0000 0000,0000,0000
DEBUG1: flip: 0000 (0000 vs 0000 in ffff - 6020)
DEBUG1: mapped to 01e, new state 0000
DEBUG1: keystrokes:
DEBUG1:   button=0x001e virtualKey=0x001d keyDown=down client=0x0000
DEBUG1: recv key up id=0x0000003d, mask=0x0000, button=0x0015
DEBUG1: keystrokes:
DEBUG1:   button=0x001e virtualKey=0x001d keyDown=up client=0x0000

I'm really interested in getting this resolved since it prevents me from using synergy. Should I also email helpdesk@synergy-project.org with my support pin or can we figure this out here?

[sgourichon]

Similar problems here. Server is Mac Mini running Mac OS X Yosemite with Apple keyboard with French Azerty layout. Client is PC with Ubuntu 14.04 with French Azerty keyboard layout. I'm surprised such problems still happen since Synergy has been existing for a long time. Did not have any problem years ago with Ubuntu PC talking with Windows 7, both Azerty keyboard. Thank you for your attention, can provide details if needed.

[dorianfm]

Also having a similar problem; Server is a Mac Laptop with OS X 10.10.2 and Synergy 1.6.2, client is Ubuntu Linux 14.10 with Synergy 1.6.2

On the Mac I have a UK Keyboard, bluetooth version which has no numeric pad. On the Linux box I have a UK keyboard, a condensed USB version with no numeric pad.

When the layout on Linux was set to US I was having strange keystrokes sent

[ on mac was sending an 8 on the Linux box ] on mac was sending a 9 on the Linux box shift+2 (which sends @) on mac was sending Ω on linux

(there may have been more, but these are the ones I noticed immediately)

Switching it to a UK layout on the Linux box solved this partially, [ and ] work correctly now, but shift+2 (which sends @) on mac still sends sends Ω on Linux. Interesting to note that @ is not shift+2 on the Linux keyboard, but a separate key.

Have so add that historically Synergy didn't have this problem - it seems to have got more buggy with time - ever since drag and drop file sharing was introduced it's just not been the same.

[conradjones]

I have this problem on two identical dell latitude e5440 laptops. Both running linux mint 17.1 and synergy 1.6.2

UK Layout keyboards (the same on both laptops)

[despairblue]

@nbolton is there any information missing we could add to help getting this resolved?

[ljrk0]

Same thing here on 2 acer Laptops with german keyboards, both set to german layout on archlinux. Client always gets US input, rather more an annoyance for me than a problem.

[ljrk0]

Maybe this helps someone else: I just set my keyboard to "de acer_laptop" (acer_laptop is the model) - and it works! Not sure whether this is just luck or really solved the problem ;-)

[despairblue]

Where did you choose that setting?

On Tue, Mar 10, 2015, 13:49 Leonard notifications@github.com wrote:

Same thing here on 2 acer Laptops with german keyboards, both set to german layout on archlinux. Client always gets US input, rather more an annoyance for me than a problem.

— Reply to this email directly or view it on GitHub https://github.com/synergy/synergy/issues/4280#issuecomment-78046473.

[ljrk0]

localectl / set x11 keyboard.

[mikehc]

I´m having issues like that using a Latin American keyboard between a PC (server) and a Mac (client), because the Mac doesn't have native support for this layout Im using a custom one. You can get it from here: http://baratijasblog.com/2009/09/07/distribucion-de-teclado-latinoamericana-para-mac-os-x/

Both machines are set to Latin American keyboard, and both machines work fine when I connect the keyboard directly to them.

[Fuxy22]

I am also having this issue I believe. Both client (linux mint 17.1) and server (windows 7) have been set to UK keyboard layout but for some reason synergy seems to think the keyboard layout on the client is the US version.

Synergy 1.6.3 is installed on both. It seems to work fine with older version of synergyc available in repo.

Mostly anyway. The @ symbol gets replaced with something else in the old version which prompted me to update but this is worse.

[yurigoul]

Maybe this might be of interest: I have two macs (10.9.5) - SERVER is a hackintosh with a german extended keyboard (PC keyboard) and CLIENT (2007 MBP) with a US keyboard - both using english as the OS language (if that is of any importance) - both using 1.6.3

TL;DR: I can use the German keyboard on the client when I set the SERVER to US and the CLIENT to German. When both are set to US the keys correspond but I can no longer see what I am typing on my keyboard :-)

Key mapping: SERVER GERMAN: üßöä !"§$% CLIENT US: uusuoua !”±$% CLIENT GERMAN: uusuoua !Ä°$%

ü = uu - ß=s ö =uo ä = ua.

The five characters following are shift + 1, 2, 3, 4, 5

Compare CLIENT GERMAN + SERVER US: üßöä !”§$%

Thanx and regards!

[tobiassodergren]

How soon is priority-soon? This issue makes synergy useless for me.

[conradjones]

Useless is a little strong, frustrating is the word i would use.

On Wed, Jun 3, 2015 at 12:22 PM, Tobias Sodergren notifications@github.com wrote:

How soon is priority-soon? This issue makes synergy useless for me.

— Reply to this email directly or view it on GitHub https://github.com/synergy/synergy/issues/4280#issuecomment-108309435.

[davidstosik]

When half your keyboard is fucked, including some numbers, that you cannot type your password, or even a simple URL (don't even think about typing punctuated text, or, worse, coding on that setup), then no, "useless" isn't strong at all.

I stopped using Synergy and turned back to VNC because of that issue. Yes, I'm losing the multi screen feature, and screen refresh sucks, but at least I know what I'm typing...

[macgeneral]

I have to agree that this bug is a show stopper! And it has been around for a very long time already! (Initial report was December 14, now we have June 15!!)

I'm using DVORAK-QWERTY as a layout on both Macs (which means QWERTY layout as soon as I hit the command key (for shortcuts) and else DVORAK). I can use the workaround to set one computer to QWERTZ or QWERTY but that only applies unless I use short cuts on the server (Command + C would translate to Command + J on the client etc.), not to mention all the special keys which make Synergy really useless! (+ translates to 0 even with that workaround)

[macgeneral]

Since then lot´s of new features have been added but the basic functionallity still does´t work!!

[conradjones]

I agree it needs resolving and should number 1 priority I,d certainly be more inclined to pay for it.

On Wed, 3 Jun 2015 12:57 Arne Fahrenwalde notifications@github.com wrote:

Since then lot´s of new features have been added but the basic functionallity still does´t work!!

— Reply to this email directly or view it on GitHub https://github.com/synergy/synergy/issues/4280#issuecomment-108338783.

[raviaw]

Same here, server is Windows 7, client is Windows 8.1, I think they have the same layout.

[tobiassodergren]

Yes, I've already bought it..

[arthursioux]

Hi there!

I found the solution in http://askubuntu.com/questions/90234/wrong-keyboard-layout-on-client-pc-when-using-synergy

Basically after starting synergyc, I put in the terminal for my spanish layout: setxkbmap es

and it works!

[conradjones]

Mine has been working great recently!

[yurigoul]

Nope, pressing ä still gives a ua on the other computer. Something something European problems.

On Fri, Jul 24, 2015 at 10:08 PM, Conrad Jones notifications@github.com wrote:

Mine has been working great recently!

— Reply to this email directly or view it on GitHub https://github.com/synergy/synergy/issues/4280#issuecomment-124699544.

[dkossako]

I changed keyboard layout to same on both PCs, AltGr key is still NOT mapped by synergy. Guys, there is a little bit diffrence between Alt and AltGr, do you know it? You can still close issues about this key but that will not fix this issue.

[tobiassodergren]

My setup is:

Server

iMac, OSX 10.10.4 Synergy 1.7.3 $ locale LANG="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_CTYPE="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8" LC_ALL=

Keyboard: US

Client

Client: MacBook Pro OSX 10.10.4 Synergy 1.7.3 $ locale LANG="sv_SE.UTF-8" LC_COLLATE="sv_SE.UTF-8" LC_CTYPE="sv_SE.UTF-8" LC_MESSAGES="sv_SE.UTF-8" LC_MONETARY="sv_SE.UTF-8" LC_NUMERIC="sv_SE.UTF-8" LC_TIME="sv_SE.UTF-8"

Using this setup, I get the following mappings:

[ -> 8 ' -> \ ; -> ,

However, if i change the keyboard to Swedish on the server, the client now get the correct keys, when still having US layout.

[tobiassodergren]

Keyboard on client is set to US the whole time.

The same problem occurs if I use English as system language for client and server, which sets the locale to C. The keys get correctly mapped when server keyboard layout is set to Swedish, but fails when using US.

[despairblue]

@LeonardKoenig just tried localectl set-x11-keymap us thinkpad on the server (linux) and restarted both, client and server, to no avail.

Pressing shift+2 still produces a capital L instead of an @. Changing the clients layout does nothing.

This happens with synergy 1.7.4 rc8 btw.

How do people use synergy with linux and mac. This is simply frustrating.

Oh and like some people already noted: using ibus to set the server layout to anything but US fixes this (I actually tried all US layouts, german and a dutch/belgian one, all US ones break synergy, and the german and dutch/belgian work), even to the extent that the client's layout can be changed and is respected by synergy. The only problem is that you don't have a US layout anymore on the server :disappointed:

I wonder if that can be fixed by copying the us layout file and calling it a different name. :confused:

[royteeuwen]

Same issue here: Macbook Pro 15 inch (mid 2015), US QWERTY keyboard Macbook Pro 15 inch (mid 2012), Belgian AZERTY keyboard

This also renders synergy useless for me.

[dkossako]

Ubuntu 14.04.3 US QWERTY Windows 8.1 US QWERTY

AltGr key is stil not mapped.

[javiergarmon]

Mac OS X 10.10 ES QWERTY Windows 10 ES QWERTY

As @djmentos, AltGr key is still not mapped.

[jlerouge]

Hi, I have the same issue too. Server: Dell Latitude E 6520 - Linux Mint 17.2 - French AZERTY Dell Keyboard (external USB keyboard) Client: MacBookPro mid 2014 - MacOS X 10.10.5 - Apple's French AZERTY Keyboard (laptop's keyboard)

I can't input an underscore '_' character, I get a minus '-' instead.

Braces '{}' and brackets '[]' are not correctly mapped, as well as the pipe '|' and the antislash '\'. To input them, I must do it the Apple way (ex: Shift+Alt+: makes a '\', Shift+Alt+l makes a '|'...)

As @djmentos and @javiergarmon, the AltGr key is not mapped (nothing shows up in xev when I stroke that key).

[tobiassodergren]

I installed Karabiner on both computers to see what the different keys were mapped to. Both are running OS X, both have the US International PC keyboard as input source. Both computer has a swedish layout on the actual keyboard buttons.

I tried to press the '['key on the keyboard on the client computer, which rendered the logs below:

Computer running the server:

Computer running the client

[NikolausDemmel]

Just another datapoint:

Server: Thinkpad, Ubuntu 14.04, German physical keyboard (external), settings switching between US and DE layouts Client: Macbook, OSX 10.9, US physical keyboard (external), settings switching between US and DE layouts

Having DE layout on the server, both layouts work fine on the client. Having US layout on the server, neither layout works properly on the client (similar mapping issue for special characters as described many times above).

[trzecieu]

Version: 1.7.4

Server:

• Windows - PC
• Logic Layout US
• Physical Layout US
• Sequence:

1234567890-=
!@#$%^&*()_+
[]\;',./
{}|:"<>?

Client:

• OSX - MacBook Pro
• Logical Keyboard: US, U.S International (Swedish doesn't work also)
• Physical Layout: Swedish
• Sequence:

1234567890/0
!@#$%}^|*(?_
897,\,.7
*(&>@~~_

[NikolausDemmel]

Maybe another interesting point: I both on my host ubuntu and client mac machine I have the system language as English, but some locale settings (like e.g. number and time formatting, time zones) as German. Maybe this plays a role? In fact when using the physical US layout on the host machine this seems to be the only thing that is specifically German. Given that the keys seem to be correct on the client only when selecting the German layout on the host, but not when selecting US or e.g. Finnish, I guess it must be some of the locale settings that are causing the trouble. Could it be that Synergy somewhere uses some of these locale settings and does an additional translation that it is not supposed to do? So with this conjecture it would behave correctly when input language and some specific locale setting matches, but incorrectly otherwise.

One way to test would be to try to switch all system settings on the server to US, use a US physical keyboard, and then check if the US logical layout on the server still fails to produce right input on the client. Of course it could also be to do with locale settings on the client, which happen to also be US for system language, but German for time, number format etc on my setup, so changing those would be an additional test.

[msewell]

To add another data point, here's how I'm experiencing this issue on Synergy 1.7.5:

Synergy server running on Windows 7. Synergy client running on Mac OS X Yosemite.

Attached to the server is a keyboard with a German physical layout.

If the server is set to use a German keyboard layout, typing works correctly on the client, regardless of which keyboard layout has been set on the client.

If the server is set to use a different keyboard layout, such as EN-US, then typing on the client is messed up (similar to how others have described it above), regardless of which keyboard layout has been set on the client.

This issue has been labeled as "priority-next" since July. Any news on the development front? Is this show-stopper being worked on at all?

[demolitions]

I had the same problem, both PCs (Linux) with IT layout, the client had US layout all the time.

I solved by executing "setxkbmap it" before both synergy server and client start.

[ghost]

@demolitions Awesome.

using setxkbmap in the Linux (Fedora) solves the problem for me too.

Thanks!

[Learath2]

Version 1.8.0/1.7.5

Server:

• Windows 7 64bit
• Layout US
• Keyboard US

Client:

• Macbook Pro OSX 10.10.1
• Layout US (tried the native layout, US - International and extended)
• Keyboard Turkish Q

US(Windows) ---> US - International PC (OSX) ~!@#$%^&*()_+ ---> N!Q#$%Hˆ_*(+$ QWERTYUIOP{}| ---> QWERTYUIOP&)+ ASDFGHJKL:" ---> ASDFGHJKL?± ZXCVBNM<>? ---> ZXCVBNM±!_

Gets some of the symbols working but obv impossible to work with... TR(Windows) ---> US - International PC (OSX) é!'^+%&/()=?_ ---> ±!@H$%ˆ&*()_+ QWERTYUIOPĞÜ; ---> QWERTYUIOPG}| ASDFGHJKLŞİ ---> ASDFGHJKLSI ZXCVBNMÖÇ: ---> ZXCVBNMOC?

US(Windows) ---> Turkish Q (OSX) ~!@#$%^&*()_+ ---> N!Q^+%H&?()_+ QWERTYUIOP{}| ---> QWERTYUIOP/=_ ASDFGHJKL:" ---> ASDFGHJKL:é ZXCVBNM<>? ---> ZXCVBNMé!?

Not to mention the modifiers dont work at all. I have tried other combinations but couldnt figure out a pattern.

This totally makes this program useless for me as it is quite important for me to have the keys []{}()*&=+-<>,.?/;:'" (basically everything that doesnt work :P)

[simonvpe]

I just paid $10 for an GPL licensed open source project that is completely useless. I use dvorak in two different varieties, not EN QWERTY or whatever single special case keyboard setup it works with. How do I get a refund or this 1.5 year old bug fixed?

Had I downloaded and built it myself (which I didnt know was possible since it isnt mentioned on the synergy-project.org) I would have moved on or tried to fix it myself but I paid top dollar and expect to get a working product which just works out of the box.

[macgeneral]

same here - I can't use Synergy at all and bought it more than 1 year ago and there's still no intent of fixing it at all... "priority-next" could be my "I'm going to do my homework soon (=> not at all)" back in highschool...

[fidergo-stephane-gourichon]

TL;DR: would you consider looking up those keywords in your favorite search engine? synergy 1.4.16 your-platform-name-eg-Windows-or-OSX

@simonvpe @macgeneral (I'm a user like you.) What is your platform? I remember around 2011-2012 things were working flawlessly using a free-as-in-freedom-and-beer version of synergy with Linux, Windows and mixture of both, and had all the features I needed at the time.

I currently no longer have the need to use it, but if I had the need again I would consider downloading an old version (for Windows and/or Mac).

Linux users probably does not need to seek and unearth old versions. Knowing the strict quality policy and maintainer availability requirements of the Debian project, I guess the fact that Debian stable ships with a synergy package is a sure sign that this version (currently 1.4.16, see https://packages.debian.org/search?keywords=synergy ) works well.

[Fire-Dragon-DoL]

For the record, I am in the same situation, since I use an Italian keyboard. I bought the software but didn't request a refund because I was fond such a problematic bug would be fixed. It wasn't, it's almost two years and this became the most disappointing software purchase.

[macgeneral]

@fidergo-stephane-gourichon: so you are suggesting to install a 4 year old version of Synergy on the latest OS X? Even if it would work without any trouble or other bugs -- not to mention security vulnerabilities (Synergy is a (local) "network service" after all) - I actually doubt it works with MacOS 10.11.4 and old versions of Synergy send every keystroke as clear text over the network... (*) This bug is a major show stopper and the devs weren't able/willing to fix it in the past 1 1/2 years.

And of course Debian is famous for shipping always with the latest version of software. (No hate there, I love Debian and CentOS for their long term support and flawless updates over many years but there would be Ubuntu and Fedora if you'd prefer more up to date software) - but suggesting this as a solution seems more like a joke to me.

The devs implemented lot's of new features in the meantime (because it's more fun I assume) - but this bug breaks the BASIC functionality of this program - I don't care about any other new feature as long as it messes up the keystrokes it's useless to me (I haven't found a functioning workaround yet).

• = Changelog (not regarding memory leaks etc.)

v1.7.2-stable

Bug #4581 - Starting GUI on Mac crashes instantly on syntool segfault

v1.7.0-beta

Enhancement #4313 - SSL encrypted secure connection

1.6.2

Bug #4249 - Drag file causes client crash on Mac (10.10)

1.6.1

Bug #4149 - Mac 10.9.5 or 10.10 gatekeeper blocks Synergy (ok I might could work around that)