Synergy-core: 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 [email protected] 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 [email protected] 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 [email protected]
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 [email protected] 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 [email protected]
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)

[Fire-Dragon-DoL]

For the record, the bad part is not really that the bug is not yet fixed (even if it is), but the fact that the bug is marked as priority-next instead of urgent, so basically all users are forced to have US qwerty keyboard, basically cutting out everyone else (which are _much_ more people than those with U.S. qwerty keyboards)

[fidergo-stephane-gourichon]

TL;DR: no offense, just pragmatism. I am a user like you. Old versions (4 years ago) just worked with local French keyboard layout and can be secured. Feel free to ignore my suggestions.

Details

@macgeneral don't get me wrong. The joke is not from me, it starts when author starts selling his GPL'ed software with major regression without taking care of the consequences in term of support expectations. When people buy something, they want bang (support) for their bucks. Else they get rightfully upset.

Regarding security, are you really considering using synergy on an untrusted network? I would think twice. Sure, many program offer built-in support for encryption, etc, but I tend to favor ad-hoc ssh tunnels. For years I've always used basic VNC clients (no support for encryption) secured through ssh tunnels.

Even with a "secure" ("pro" haha) version of synergy, I would consider typing passwords on the computer-local keyboard only anyway, not on the shared keyboard. If you're serious about security, you should consider telling the OS to allow synergy to communicate only with selected hosts (no access to the Internet), just in case.

Conclusion: how I got the job done

All in all, if you need the features, setting up a version of synergy:

• that is very old but works no regression
• with only the needed features (less features means less reasons to break),
• that gets the job done and
• secured by means we control (instead of a label on the cardboard box that says "it is secure")
• ...is, IMHO, better than nothing.

It's not a joke, it's how we get out of the joke (and the reality distortion field that make people believe that they _need_ the latest, even when the older is the only one that works).

[Fire-Dragon-DoL]

@fidergo-stephane-gourichon Actually it's not that I don't like your approach, is the fact that one of my system is OSX based, so I guess I'm screwed in some way

[simonvpe]

I would be happy to contribute and rework the keyboard backend in order to fix this issue but I do not want someone to charge $10 a pop for software that I designed.

[XinyuHou]

Server: Windows 10 64bit Italian keyboard layout (doesn't really matter which OS server is on)
Client: Mac El Capitan Italian keyboard layout

From @stemig
Server and cliente log

1. Connect client to server
2. Use Italian keyboard layout on both server and client
3. Pressing '.'
4. ',' is typed on client

Here other problems I've noticed:
Pressing '+' expected '+' returns nothing
Pressing 'alt gr + è' expected '[' returns 'è'
Pressing 'alt gr + shift + è' expected '{' returns 'è'
Pressing 'alt gr + +' expected ']' returns '+'
Pressing 'alt gr + shift + +' expected '}' returns '*'

[XinyuHou]

Comment from @kharenzze
https://github.com/symless/synergy/issues/2765#issuecomment-215550804

[conradjones]

Fork it. It's GPL.
On 7 Apr 2016 8:28 a.m., "Simon Pettersson" [email protected]
wrote:

I would be happy to contribute and rework the keyboard backend in order to
fix this issue but I do not want someone to charge $10 a pop for software
that I designed.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-206737385

[ehuott]

@fidergo-stephane-gourichon, My analysis of the situation was virtually the same as yours. I documented my workaround to this problem using older (free) versions of Synergy here:

https://github.com/symless/synergy/issues/2765#issuecomment-193117594

@Fire-Dragon-DoL, @simonvpe and @macgeneral may also be interested.

It seems like this bug is finally getting enough attention that they're starting to work on it. We'll see what happens!

[skimboarder]

Ran into this issue the other day. Been using the program for awhile and have not seen this, until then.

It had a simple and pretty obvious fix. I restarted the Server computer, and voila! Keyboard returned to mapping correctly on both client and server.

[joonas-fi]

I was considering on buying Synergy, but seeing it doesn't support non-US keyboard layouts AND learning that the devs are not interested in fixing this (there have been reports forever for keys not working), I don't want anything to do with this software. I tried asking for help on the IRC channel -> no response in 3 hours.

All I've seen is suggestions on removing Windows updates. There's even a script that does it automatically for you. Is this a joke? I'm not going to make my computer insecure by removing updates. Why not fix the problem itself, since it's clearly an issue with Synergy as the competitor's software works perfectly? Input Director is free, the stable version has not been updated in more than six years, and it works out of the fucking box.

Replaying keyboard and mouse events on another computer sounds like a weekend project for a good coder. Why do you expect people to pay 30 bucks (encryption is a must) for a software that is fundamentally broken for most of the people in the world and you have no intent on fixing it?

And Symless? Who wants to have "less" on their company name? It certainly is apt here, though. :)

[brunovianarezende]

just as another data point, I also get this:

Linux host to linux client @ (shift + 2) producing Ω instead

when I use Linux host and windows client, it works ok.

[orcinus]

Jesus christ, still nothing?
This has been broken for over a decade now.

It's been flagged as a bug and priority-next for what - two years?
It fucking works in 1.3. What are you people doing? Stop wasting time on SSL and new sites and picking the music for your promo video and fix the damned regression.

[kharenzze]

@orcinus Agree. This is the main feature of the app... It should be top priority

[XinyuHou]

Windows 7 server
Fedora client
Synergy 1.8.1 beta

Repo:

1. Lock client
2. Lock server
3. Wake server
4. Wake client

Result: Keys are mismatched
Workaround: Reboot server

[dorianfm]

@XinyuHou REBOOT is hardly a workaround. Something that fails so hard you have to reboot doesn't deserve to be installed on a computer.

It's an insult for someone from Symless to even suggest that, especially to people who have paid for licenses to software they cannot use because of a regression in the codebase.

If symless are going to post on this communicating that they are acting on it and projecting a timeline for resolution would be more appropriate.

[orcinus]

Windows 8.1 server
Mac OS client
ANY version of Synergy since 1.3

Repro:

1. Install Synergy
2. Run Synergy
3. Hit the '/? key (next to 0)
4. Outputs 7 (WTF?!)

Result: Synergy is useless
Workaround: Use a horribly outdated version of Synergy client from 2003. without SSL and clipboard.

[ehuott]

@orcinus I have working cut and paste with Synergy 1.3.1 on Mac OS X and Synergy 1.4.12 on Ubuntu. Maybe if you could get the same version for Windows 8.1 it would work?

For encryption, I use ssh and forward port 24800 (synergy) through the tunnel.

Additional details and comments here:
https://github.com/symless/synergy/issues/2765#issuecomment-193117594

Edit: Hmmm... It looks like the comment link above might not work if all the comments have not been loaded onto the page. This looks like a GitHub bug that I hope they will fix soon.

[brunovianarezende]

another one:

• ubuntu server - latest version
• mac os X client - latest version

If I use '/' the key code sent is 7 (checked with ukelele) and the key displayed is 'q'. If I put the keyboard in the mac mini and check again, the code is 94 and all works ok. A similar problema happens with '?': the key code sent is 8 and 'w' is displayed, if I connect the keyboard to the mac mini the key code is 95 and all works ok.

This issue is annoying. I have a ubuntu server, a laptop with client that usually runs a ubuntu too, but some times runs windows, and a mac mini client. My ideal world would be to be able to just use the keyboard without doing any workaround, but it fails both in ubuntu client and in mac mini client.

[orcinus]

@ehuott Thanks for the tip. I had 1.4.something running on Windows 8.1, but there were issues. Don't remember what they were anymore (i think general instability / constant disconnecting), but maybe it's time to revisit it, it can't be worse than this.

[davidstosik]

1. Install 1.8.3 nightly release on two Macbook Pros (2010 French and 2015 Japanese) running OS X El Capitan (10.11.5).
2. Set Synergy to be server on the 2015 MBP, and client on the 2010 MBP.
3. Reboot.
4. Connect.
5. Start typing punctuation characters using shift key on the server.
6. Find out the client is still outputting garbage.

Result: NOT SOLVED.
Workaround: FIX IT!

[RainofTerra]

synergy-v1.8.3-beta-723a8a9-MacOSX1011-x86_64 on client, synergy-v1.8.3-beta-723a8a9-Windows-x64 on server. shift-(forward slash to the left of right shift) produces ? as expected but I can't actually produce a forward-slash, it just beeps. If I try to run the "press the key to the right and left of shift" test to have OS X figure out my keyboard layout, it says OS X didn't recognize the key. Let me know if you need more information or for me to perform further tests. US keyboard layout on both using a tenkeyless Leopold USB keyboard.

[scramble45]

When I press the forward slash on the server side using matching US keyboard layouts from Windows (Server side) client (Mac) I get the following output when monitoring the key codes on the mac:

Key Down
Characters: 
Unicode: 30 / 0x1e
Keys: 
Key Code: 77 / 0x4d
Modifiers: 0 / 0x0

Key Up
Characters: 
Unicode: 30 / 0x1e
Keys: 
Key Code: 77 / 0x4d
Modifiers: 0 / 0x0

Pretty sure it should be something like this instead:

Key Down
Characters: /
Unicode: 47 / 0x2f
Keys: /
Key Code: 44 / 0x2c
Modifiers: 256 / 0x100 ⓘ

Key Up
Characters: /
Unicode: 47 / 0x2f
Keys: /
Key Code: 44 / 0x2c
Modifiers: 256 / 0x100 ⓘ

[ALenfant]

Same issue here with Windows server (AZERTY keyboard) and OSX client (QWERTY one). I'm really disappointed since I bought a licence and would've expected it to work out of the box...

[XinyuHou]

Hi there,
I'm using OS X as server and Ubuntu 15.10 as client and when I type with Magic Keyboard for chars { , [ , ], } (and I don't know if there are others), in Ubuntu they do not show up, as if they got lost.
I tested this on OS X with versions 1.7.6 and 1.8.0 beta and on Ubuntu with 1.7.6.
Thank you.
Alexander.

EDIT: I though only after seeing this (#5394) that it could be related to an unsupported Alt-GR.

[alexandercerutti]

I want to add to the previous comment (the quote) that Ubuntu 15.10 key map screen, detects that when pressing most dead keys (like Alt Gr, Tabulator, Command, Option (Alt-left), Backspace), it is like I'm fastly pressing the key "Shift Left" for about some milliseconds.

[reesew]

Here is some data from the debug logs while using a custom keyboard layout. I'm using Windows as the server, and Ubuntu and Mac as clients. For these logs, I pressed the same 4 keys for both clients for comparison between expected behavior (Ubuntu's) and actual behavior (Mac's). The keys work as expected in the Ubuntu client, but the Mac client is messed up.

synergys 1.7.6, Windows 10 x64
synergyc 1.7.6, Ubuntu 16.04
[2016-07-05T14:15:15] DEBUG1: recv key down id=0x0000005b, mask=0x2000, button=0x0002
[2016-07-05T14:15:15] DEBUG1: mapKey 005b (91) with mask 2000, start state: 2000
[2016-07-05T14:15:15] DEBUG1: find best:  2000 2000
[2016-07-05T14:15:15] DEBUG1: best key index 0 of 1 (exact)
[2016-07-05T14:15:15] DEBUG1: found key in group 0
[2016-07-05T14:15:15] DEBUG1: state: 2000,0000,0001
[2016-07-05T14:15:15] DEBUG1: flip: 0000 (2000 vs 0000 in 0001 - 0000)
[2016-07-05T14:15:15] DEBUG1: desired state: 2000 2000,0000,0001
[2016-07-05T14:15:15] DEBUG1: flip: 0000 (2000 vs 2000 in fffe - 6020)
[2016-07-05T14:15:15] DEBUG1: mapped to 00a, new state 2000
[2016-07-05T14:15:15] DEBUG1: keystrokes:
[2016-07-05T14:15:15] DEBUG1:   00a (00000000) down
[2016-07-05T14:15:15] DEBUG1: recv key up id=0x0000005b, mask=0x2000, button=0x0002
[2016-07-05T14:15:15] DEBUG1: keystrokes:
[2016-07-05T14:15:15] DEBUG1:   00a (00000000) up

[2016-07-05T14:15:16] DEBUG1: recv key down id=0x00000028, mask=0x2000, button=0x0003
[2016-07-05T14:15:16] DEBUG1: mapKey 0028 (40) with mask 2000, start state: 2000
[2016-07-05T14:15:16] DEBUG1: find best:  2000 2000
[2016-07-05T14:15:16] DEBUG1: best key index 0 of 2 (exact)
[2016-07-05T14:15:16] DEBUG1: found key in group 0
[2016-07-05T14:15:16] DEBUG1: state: 2000,0000,0001
[2016-07-05T14:15:16] DEBUG1: flip: 0000 (2000 vs 0000 in 0001 - 0000)
[2016-07-05T14:15:16] DEBUG1: desired state: 2000 2000,0000,0001
[2016-07-05T14:15:16] DEBUG1: flip: 0000 (2000 vs 2000 in fffe - 6020)
[2016-07-05T14:15:16] DEBUG1: mapped to 00b, new state 2000
[2016-07-05T14:15:16] DEBUG1: keystrokes:
[2016-07-05T14:15:16] DEBUG1:   00b (00000000) down
[2016-07-05T14:15:16] DEBUG1: recv key up id=0x00000028, mask=0x2000, button=0x0003
[2016-07-05T14:15:16] DEBUG1: keystrokes:
[2016-07-05T14:15:16] DEBUG1:   00b (00000000) up

[2016-07-05T14:15:16] DEBUG1: recv key down id=0x00000029, mask=0x2000, button=0x0004
[2016-07-05T14:15:16] DEBUG1: mapKey 0029 (41) with mask 2000, start state: 2000
[2016-07-05T14:15:16] DEBUG1: find best:  2000 2000
[2016-07-05T14:15:16] DEBUG1: best key index 0 of 2 (exact)
[2016-07-05T14:15:16] DEBUG1: found key in group 0
[2016-07-05T14:15:16] DEBUG1: state: 2000,0000,0001
[2016-07-05T14:15:16] DEBUG1: flip: 0000 (2000 vs 0000 in 0001 - 0000)
[2016-07-05T14:15:16] DEBUG1: desired state: 2000 2000,0000,0001
[2016-07-05T14:15:16] DEBUG1: flip: 0000 (2000 vs 2000 in fffe - 6020)
[2016-07-05T14:15:16] DEBUG1: mapped to 00c, new state 2000
[2016-07-05T14:15:16] DEBUG1: keystrokes:
[2016-07-05T14:15:16] DEBUG1:   00c (00000000) down
[2016-07-05T14:15:16] DEBUG1: recv key up id=0x00000029, mask=0x2000, button=0x0004
[2016-07-05T14:15:16] DEBUG1: keystrokes:
[2016-07-05T14:15:16] DEBUG1:   00c (00000000) up

[2016-07-05T14:15:17] DEBUG1: recv key down id=0x0000007b, mask=0x2000, button=0x0005
[2016-07-05T14:15:17] DEBUG1: mapKey 007b (123) with mask 2000, start state: 2000
[2016-07-05T14:15:17] DEBUG1: find best:  2000 2000
[2016-07-05T14:15:17] DEBUG1: best key index 0 of 1 (exact)
[2016-07-05T14:15:17] DEBUG1: found key in group 0
[2016-07-05T14:15:17] DEBUG1: state: 2000,0000,0001
[2016-07-05T14:15:17] DEBUG1: flip: 0000 (2000 vs 0000 in 0001 - 0000)
[2016-07-05T14:15:17] DEBUG1: desired state: 2000 2000,0000,0001
[2016-07-05T14:15:17] DEBUG1: flip: 0000 (2000 vs 2000 in fffe - 6020)
[2016-07-05T14:15:17] DEBUG1: mapped to 00d, new state 2000
[2016-07-05T14:15:17] DEBUG1: keystrokes:
[2016-07-05T14:15:17] DEBUG1:   00d (00000000) down
[2016-07-05T14:15:17] DEBUG1: recv key up id=0x0000007b, mask=0x2000, button=0x0005
[2016-07-05T14:15:17] DEBUG1: keystrokes:
[2016-07-05T14:15:17] DEBUG1:   00d (00000000) up

============================

synergys 1.7.6, Windows 10 x64
synergyc 1.7.6, Mac 10.11
[2016-07-05T14:22:57] DEBUG1: recv key down id=0x0000005b, mask=0x2000, button=0x0002
[2016-07-05T14:22:57] DEBUG1: mapKey 005b (91) with mask 2000, start state: 0000
[2016-07-05T14:22:57] DEBUG1: find best:  0000 2000
[2016-07-05T14:22:57] DEBUG1: best key index 0 of 1 (exact)
[2016-07-05T14:22:57] DEBUG1: found key in group 0
[2016-07-05T14:22:57] DEBUG1: state: 0000,0000,0000
[2016-07-05T14:22:57] DEBUG1: flip: 0000 (0000 vs 0000 in 0000 - 0000)
[2016-07-05T14:22:57] DEBUG1: desired state: 2000 0000,0000,0000
[2016-07-05T14:22:57] DEBUG1: flip: 0000 (0000 vs 2000 in ffff - 6020)
[2016-07-05T14:22:57] DEBUG1: mapped to 022, new state 0000
[2016-07-05T14:22:57] DEBUG1: keystrokes:
[2016-07-05T14:22:57] DEBUG1:   button=0x0022 virtualKey=0x0021 keyDown=down client=0x0000
[[2016-07-05T14:22:57] DEBUG1: recv key up id=0x0000005b, mask=0x2000, button=0x0002
[2016-07-05T14:22:57] DEBUG1: keystrokes:
[2016-07-05T14:22:57] DEBUG1:   button=0x0022 virtualKey=0x0021 keyDown=up client=0x0000

[2016-07-05T14:22:58] DEBUG1: recv key down id=0x00000028, mask=0x2000, button=0x0003
[2016-07-05T14:22:58] DEBUG1: mapKey 0028 (40) with mask 2000, start state: 0000
[2016-07-05T14:22:58] DEBUG1: find best:  0000 2000
[2016-07-05T14:22:58] DEBUG1: best key index 0 of 1 (exact)
[2016-07-05T14:22:58] DEBUG1: found key in group 0
[2016-07-05T14:22:58] DEBUG1: state: 0000,0000,0000
[2016-07-05T14:22:58] DEBUG1: flip: 0000 (0000 vs 0000 in 0000 - 0000)
[2016-07-05T14:22:58] DEBUG1: desired state: 2000 0000,0000,0000
[2016-07-05T14:22:58] DEBUG1: flip: 0000 (0000 vs 2000 in ffff - 6020)
[2016-07-05T14:22:58] DEBUG1: mapped to 01a, new state 0000
[2016-07-05T14:22:58] DEBUG1: keystrokes:
[2016-07-05T14:22:58] DEBUG1:   button=0x001a virtualKey=0x0019 keyDown=down client=0x0000
9[2016-07-05T14:22:58] DEBUG1: recv key up id=0x00000028, mask=0x2000, button=0x0003
[2016-07-05T14:22:58] DEBUG1: keystrokes:
[2016-07-05T14:22:58] DEBUG1:   button=0x001a virtualKey=0x0019 keyDown=up client=0x0000

[2016-07-05T14:22:58] DEBUG1: recv key down id=0x00000029, mask=0x2000, button=0x0004
[2016-07-05T14:22:58] DEBUG1: mapKey 0029 (41) with mask 2000, start state: 0000
[2016-07-05T14:22:58] DEBUG1: find best:  0000 2000
[2016-07-05T14:22:58] DEBUG1: best key index 0 of 1 (exact)
[2016-07-05T14:22:58] DEBUG1: found key in group 0
[2016-07-05T14:22:58] DEBUG1: state: 0000,0000,0000
[2016-07-05T14:22:58] DEBUG1: flip: 0000 (0000 vs 0000 in 0000 - 0000)
[2016-07-05T14:22:58] DEBUG1: desired state: 2000 0000,0000,0000
[2016-07-05T14:22:58] DEBUG1: flip: 0000 (0000 vs 2000 in ffff - 6020)
[2016-07-05T14:22:58] DEBUG1: mapped to 01e, new state 0000
[2016-07-05T14:22:58] DEBUG1: keystrokes:
[2016-07-05T14:22:58] DEBUG1:   button=0x001e virtualKey=0x001d keyDown=down client=0x0000
0[2016-07-05T14:22:58] DEBUG1: recv key up id=0x00000029, mask=0x2000, button=0x0004
[2016-07-05T14:22:58] DEBUG1: keystrokes:
[2016-07-05T14:22:58] DEBUG1:   button=0x001e virtualKey=0x001d keyDown=up client=0x0000

[2016-07-05T14:22:59] DEBUG1: recv key down id=0x0000007b, mask=0x2000, button=0x0005
[2016-07-05T14:22:59] DEBUG1: mapKey 007b (123) with mask 2000, start state: 0000
[2016-07-05T14:22:59] DEBUG1: find best:  0000 2000
[2016-07-05T14:22:59] DEBUG1: best key index 0 of 1 (exact)
[2016-07-05T14:22:59] DEBUG1: found key in group 0
[2016-07-05T14:22:59] DEBUG1: state: 0000,0000,0000
[2016-07-05T14:22:59] DEBUG1: flip: 0000 (0000 vs 0000 in 0000 - 0000)
[2016-07-05T14:22:59] DEBUG1: desired state: 2000 0000,0000,0000
[2016-07-05T14:22:59] DEBUG1: flip: 0000 (0000 vs 2000 in ffff - 6020)
[2016-07-05T14:22:59] DEBUG1: mapped to 022, new state 0000
[2016-07-05T14:22:59] DEBUG1: keystrokes:
[2016-07-05T14:22:59] DEBUG1:   button=0x0022 virtualKey=0x0021 keyDown=down client=0x0000
[[2016-07-05T14:22:59] DEBUG1: recv key up id=0x0000007b, mask=0x2000, button=0x0005
[2016-07-05T14:22:59] DEBUG1: keystrokes:
[2016-07-05T14:22:59] DEBUG1:   button=0x0022 virtualKey=0x0021 keyDown=up client=0x0000

Everything used to work, e.g. in Synergy 1.3.7-1.3.8. Can the relevant portion of the code from that version be copied or ported to get this working again?

[XinyuHou]

I'm a Unity programmer using MonoDevelop as IDE, for some reason Synergy and MonoDevelop seems to be fighting each other to understand on the client what keystrokes are being pressed.
Both client and server are Windows 10 and some keys simply don't work on MonoDevelop, and that´s probably MonoDevelop fault for being an terrible program, but I was poking around to see if I could fix it somehow and noticed that Synergy are sending "weird" keystrokes in shortcut setting, for example: "ctrl+alt+q" shows "ctrl+alt+/", "ctrl+alt+c" shows "ctrl+alt\u20a2", since others combinations don´t show anything weird, like "ctrl+alt+a" I thought was a Keyboard Layout issue, since both my laptop and desktop (client and server) use the same kind of keyboard (Portuguese (Brazil ABNT)) I can´t really change the layout (because there are special keys in my freaking keyboard like "ç"), although when changing to US, it screws even mode.
The problem is in MonoDevelop the "/" (forward slash) are recognized as ctrl+alt+q and ctrl+alt+c = cltr+alt+w, this is just some examples to what are show in Key Bindings in MonoDevelop.
While I'm aware this is a MonoDevelop issue (I really wanted to change IDE, but I don´t want to ever deal with VS), I´m reporting it anyway because even on server side synergy seems to be showing the wrong character so most likely is a layout problem that may need to be addressed and hopefully fix my problem.

synergy-server.txt
synergy-client.txt

I'm appending the logs while trying to keypress some of the keys that gives problems, hopefully it's of some use for you guys.

[dorianfm]

Before I try installing 1.8 - is this issue fixed in it? If not can we get some idea when it will be fixed, as I can't use the current version until resolved, and it's been going for 1.5 years...

[yurigoul]

Just tested, the answer is... wait for it ... no.

sorry....

On Wed, Aug 10, 2016 at 11:55 AM, Dorian Fraser Moore <
[email protected]> wrote:

Before I try installing 1.8 - is this issue fixed in it? If not can we get
some idea when it will be fixed, as I can't use the current version until
resolved, and it's been going for 1.5 years...

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

[tobiassodergren]

I completely agree with the priorities:

Bug #2975 - Middle click does not close Chrome tab on Mac client
Bug #5471 - Serial key textbox on activation screen overflows on Mac
Bug #4836 - Stop button resets to Start when settings dialog canceled
Enhancement #5299 - High resolution App icon on Mac
Enhancement #4894 - Improve grammar in connection notification dialog

These must of course be more important than sending the correct keys to the client.

[Fire-Dragon-DoL]

I paid for this and still can't use it after 2 years, would have expected this to be high priority 😞

[orcinus]

2 years? Try 10+.

[Fire-Dragon-DoL]

@orcinus 2 years since the compiled version was put behind a paywall

[orcinus]

Ah, right.
2 years since insult and 10 since the injury, how's that?

[XinyuHou]

Hello @nbolton, I'm a Beta tester for Synergy 1.8. Even though I'm a beta tester for 1.8 this is an old issue ever since I started using Synergy in version 1.3.
I'm using a windows 10 64bits server and a Mac 10.11 Client but this issue can also be observed when client and server as reversed.
Both keyboards are United States International Layout, using Brazilian Portuguese as Input language.
I'm Unable to send Accented Characters to the client. In Portuguese we have accented characters like ã à á â ç. I'm also unable to send quotes " and apostrophe ' to the client.
For example: In order to make a "á" character we should type Apostrophe and the letter "A".

Here are some examples of Client Output while trying to type these characters on the Server:

Obs: The keys aren't pressed at the same time. You should press the first one (Using shift if it applies), release, and then press the second.

ã: Tilde + a / Output: na
õ: Tilde + o / Output: no
á: Apostrophe + a / Output: ea
é: Apostrophe + e / Output: ee
ó: Apostrophe + o / Output: eo
â: Caret + a / Output: 6a
ô: Caret + o / Output: 6o
ä: Quotes + a / Output: ua
ö: Quotes + o / Output: uo
ç: Apostrophe + c / Output: c
' : Apostrophe + Space / Output: Nothing
" : Quotes + Space / Output: Nothing

There seems to be a pattern while trying to make those characters. Tilde is being replaced for the letter "n" while Apostrophe for the letter "e", Caret for the number "6" and Quotes for the letter "u".

While there are replacements when trying to use theses keys to form Accented Characters using Apostrophe and Quotes, when pressed alone the output is just Null.

Obs2: The Crasis "`" Accent seems to be the only one that works fine. I can make the characters accented with Grave key + Letter just fine: à è ì ò ù. (Crasis à is different than Acute á)

General Info:

Server OS: Windows 10 64bits English
Server Keyboards Layout: United States International
Server Input Language: Brazilian Portuguese
Client OS: Mac OS 10.11 English
Client Keyboard Layout: United States International
Client Input Language: Brazilian Portuguese
Synergy Version: 1.82
Software Where Issue Where Observed: Any (Microsoft Word, Safari, Chrome, Notes...)

Obs3: The issue does not affect typing theses characters locally both on the Server or on the Client.

[mnmelo]

I'm just adding a 'me too' comment to this bug, and offering to carry out some testing, if needed.
(And that 'priority-urgent' tag sure is hopeful!)

Server OS: Ubuntu 14.04
Server Keyboards Layout: United States International
Server Input Language: Portuguese
Client OS: Mac OS 10.11 English
Client Keyboard Layout: English, International
Client Input Language: Portuguese
Synergy Version: 1.82-stable-36cd521

[yurigoul]

Me too

Hackintosh osx 10.9 German keyboard

2007 MacBook pro same os with int. English/dutch keyboard

On 16 Aug 2016 22:20, "mnmelo" [email protected] wrote:

I'm just adding a 'me too' comment to this bug, and offering to carry out
some testing, if needed.
(And that 'priority-urgent' tag sure is hopeful!)

Server OS: Ubuntu 14.04
Server Keyboards Layout: United States International
Server Input Language: Portuguese
Client OS: Mac OS 10.11 English
Client Keyboard Layout: English, International
Client Input Language: Portuguese
Synergy Version: 1.82-stable-36cd521

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

[m4limo]

Same here!

_Setup:_
Two macs (OS X El Capitan 10.11.6)
German keyboard layout (DE) on both.

_What I observed:_
If I set the host to EN and the client to DE everything works fine.

[yurigoul]

alt+u-u on the host gives ü on the client?

[email protected]
017681773842
www.AlienSaints.com

On Wed, Aug 17, 2016 at 2:35 PM, m4limo [email protected] wrote:

Same here!

_Setup:_
Two macs (OS X El Capitan 10.11.6)
German keyboard layout (DE) on both.

_What I observed:_
If I set the host to EN and the client to DE everything works fine.

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

[m4limo]

@yurigoul no alt+u-u on the host does not give me ü on the client.
if both machines are set to DE (QWERTZ), I get something like the EN keyboard layout on the client (QWERTY). If I set my client to EN (server still DE) I get something like the DE keyboard layout on the client (QWERTZ).
And almost all special characters are messed up:

ü -> uu _(ue would be the correct fallback)_
ä -> ua _(ae would be the correct fallback)_
ö -> uo _(oe would be the correct fallback)_
ß -> s _(sz would be the correct fallback)_

# -> 3
+ -> =
/ -> ?
= -> +
´ -> e
' -> "
< -> ,
^ -> *
° -> 6

and so on... these are just the obvious ones, don't get me started if the ALT key is involved...

[sankarmenon]

Key mismatch from Source to Client.

Server OS: Ubuntu 14.04
Server Keyboards Layout: English (macintosh)
Server Input Language: English
Client OS: Mac OS 10.11 English
Client Keyboard Layout: US
Client Input Language: English
Synergy Version: 1.8.2-stable-130a248

[tenleftfingers]

The latest update is still affected, I have a server/client running each Ubuntu 16.04. I don't regret paying for this either way - $10 is insanely good value. But I can't go switching the other machines keyboard layouts to fix this, it's just not practical.

I'm happy to run any test / produce any reports.

Edit: I think we will be a long time waiting for a fix to this issue. I won't ask for a refund, but for anyone else who can't use synergy now I've found a helpful thread here: https://www.reddit.com/r/LifeProTips/comments/1pqu96/if_you_use_a_multicomputer_setup_try_garage_mouse/

[puncher72]

I use two laptops, both on Windows English 10, lets name them red laptop and green laptop. Both have two languages installed, US English and Greek (not only keyboard functionality but also system language installed). Default is US English. I also have set USA as country in regional settings just to be ok with Synergy although I am not in USA.

I have a wireless combo of mouse & keyboard. I don't have USB port functionality on the green laptop (broken ports). Because I write my reports (using English and Greek) on the green laptop and I want to be faster I want to use the combo instead of the touchpad and built-in keyboard. I have the combo connected to the red laptop (server) and use Synergy 1.5.1, so I will have the combo functionality on the green laptop (guest) as well. Let me describe now the issues.

Wireless mouse work perfectly on green through Synergy. Fast and precise. The problem is with the keyboard transfer. When I want to type in English on green using Synergy (using either the built keyboard in red laptop or the wireless keyboard) everything works perfectly. No mishaps or letters inconsistency.

Problems
1) In the first case I have English keyboard activated on red and switch to green. When I change the language to Greek (using either alt+shift from red or green or wireless keyboard) then I cannot use Greek on green. I want to be tell you that when I do that of course the language does not change in red laptop as it should. I have Greek activated on the bottom right (ΕΛ) but when I try to type in instantly turns to ENG and types English characters wherever I type. This happens to every software I have.

2) In the second case - and after reading online Synergy solutions - I close the server on red, change the keyboard to Greek on red, rerun the server, rerun Synergy on green and switch to green. When I change then the language to Greek (using either alt+shift from red or green or wireless keyboard) then I cannot use Greek or English anymore on green through the red built-in keyboard or wireless keyboard. Only built-in green keyboard works. Whenever I try to type, it does not type anything at all, like the keyboards do not work.

I really do not know how to fix it. I tried many solutions online, like resetting keyboard settings on server, quit and restarting server and nothing works. Do you have an idea?

Thank you for any response.

[yurigoul]

Yoohoo!!

Synergy 183-stable-db9181b gives me matching keys and diacriticals (öüä
etc) on the client machine, as well as working media keys - server osx
10.9.5 Hackintosh with German PC keyboard/client osx 10.9.5 macbook pro
with build in US/NL keyboard

I believe most alt key combinations are working, except for alt-key
combinations with the top row number keys

How are other people doing?

[email protected]
017681773842
www.AlienSaints.com

On Tue, Sep 20, 2016 at 4:23 PM, puncher72 [email protected] wrote:

I use two laptops, both on Windows English 10, lets name them red laptop
and green laptop. Both have two languages installed, US English and Greek
(not only keyboard functionality but also system language installed).
Default is US English. I also have set USA as country in regional settings
just to be ok with Synergy although I am not in USA.

I have a wireless combo of mouse & keyboard. I don't have USB port
functionality on the green laptop (broken ports). Because I write my
reports (using English and Greek) on the green laptop and I want to be
faster I want to use the combo instead of the touchpad and built-in
keyboard. I have the combo connected to the red laptop (server) and use
Synergy 1.5.1, so I will have the combo functionality on the green laptop
(guest) as well. Let me describe now the issues.

Wireless mouse work perfectly on green through Synergy. Fast and precise.
The problem is with the keyboard transfer. When I want to type in English
on green using Synergy (using either the built keyboard in red laptop or
the wireless keyboard) everything works perfectly. No mishaps or letters
inconsistency.

Problems
1) In the first case I have English keyboard activated on red and switch
to green. When I change the language to Greek (using either alt+shift from
red or green or wireless keyboard) then I cannot use Greek on green. I want
to be tell you that when I do that of course the language does not change
in red laptop as it should. I have Greek activated on the bottom right (ΕΛ)
but when I try to type in instantly turns to ENG and types English
characters wherever I type. This happens to every software I have.

2) In the second case - and after reading online Synergy solutions - I
close the server on red, change the keyboard to Greek on red and switch to
green. When I change then the language to Greek (using either alt+shift
from red or green or wireless keyboard) then I cannot use Greek or English
anymore on green through the red built-in keyboard or wireless keyboard.
Only built-in green keyboard works. Whenever I try to type, it does not
type anything at all, like the keyboards do not work.

I really do not know how to fix it. I tried many solutions online, like
resetting keyboard settings on server, quit and restarting server and
nothing works. Do you have an idea?

Thank you for any response.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-248316242,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa33HdniNk70ozx7F5_tE8q_EHdlVks5qr-xagaJpZM4DJe4x
.

[puncher72]

I decided to abandon the idea of using Synergy 8 days now since not only I had the problem with the Greek keyboard but also realized that all non-letter and non-number keys were not working as well. They were writing other symbols than the ones I typed. The guest laptop was also continuously losing connection with the server laptop although I have extremely quick fiber internet and at the same time do not lose the internet connection. I had to restart the server many times in 1 hour. So I am back to my old tricks using TeamViewer 11 remote screen control so I can use my wireless combo on my guest laptop through my server laptop. At least with this I do not have any keyboard irregularities and the connection is stable. In one word synergy....disappointment!

[sy-bee]

It improved a lot! Even though not perfect, there are still mismatched letters for setups like: English keyboard on server (Ubuntu), Russian Phonetic on client (Mac). However English -> English (irish keyboard layout) works perfect now!

[orcinus]

Holy shit! You've finally fixed it!

Windows 10 server Croatian layout --> Mac OS X 10.12 Croatian layout
Synergy 1.8.3-stable-db9181b on both sides

IT FINALLY WORKS!

[davidstosik]

Holy shit, yes! This is an unexpected surprise, but it seems to be working now. I had dropped Synergy for a while, just checking in on this thread one in a while. Installed and tried the newest stable version today, and it seems to be working so far.

Server: Macbook Pro with Japanese keyboard.
Client: Macbook Pro with French keyboard.

Setup both client and server, didn't change anything to my keyboard configurations, and it worked right away. There may still be some issues with Japanese IME, but hey, Synergy is now usable, so that's cool.

Thanks and congrats on the fix!

[orcinus]

There still are some issues, mind you, but at least the layout is correct.

The modifier keys (shift, as of late) gets stuck randomly on the client, and then you have to move to the server and mash shift for a bit until it releases. And the cursor on the client (on Mac OS at least) gets hidden when the focus is on the server _but_ doesn't get displayed if you touch the client's own touchpad/mouse (but it still moves around and clicks, it's just that it's invisible).

[yurigoul]

I would start a separate issue/ticket for this since this is not a mapping
problem

On 2 Oct 2016 13:37, "Ante Vukorepa" [email protected] wrote:

There still are some issues, mind you, but at least the layout is correct.

The modifier keys (shift, as of late) gets stuck randomly on the client,
and then you have to move to the server and mash shift for a bit until it
releases. And the cursor on the client (on Mac OS at least) gets hidden
when the focus is on the server _but_ doesn't get displayed if you touch
the client's own touchpad/mouse (but it still moves around and clicks, it's
just that it's invisible).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-250966996,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa3CQFM9Tlmn_kbifd_hR8pjWpl12ks5qv5eHgaJpZM4DJe4x
.

[NikolausDemmel]

What a unexpected pleasent surprise. 1.8.3 seems to have improved things indeed. I only even gave it a try because of the replys here.

I have a Linux server and Mac client, with both English and German layouts on server and client, and a German physical keyboard on the server.

Most keys including SHIFT+key combinations seem to work for my setup. As far as I can tell for those the client layout is ignored and the one on the server is used.

What is interesting is that many ALT+key or ALTGR+key combinations work such that the _client_ keyboard layout is used, not the server, but not all of them.

But finally I can at least type umlauts and such at all.

[orcinus]

I will, don't worry.
Just mentioned it here in passing while i try to find a reliable way to reproduce it.

On 2 Oct 2016, at 13:45, yurigoul [email protected] wrote:

I would start a separate issue/ticket for this since this is not a mapping
problem

On 2 Oct 2016 13:37, "Ante Vukorepa" [email protected] wrote:

There still are some issues, mind you, but at least the layout is correct.

The modifier keys (shift, as of late) gets stuck randomly on the client,
and then you have to move to the server and mash shift for a bit until it
releases. And the cursor on the client (on Mac OS at least) gets hidden
when the focus is on the server _but_ doesn't get displayed if you touch
the client's own touchpad/mouse (but it still moves around and clicks, it's
just that it's invisible).

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-250966996,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa3CQFM9Tlmn_kbifd_hR8pjWpl12ks5qv5eHgaJpZM4DJe4x
.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[ehuott]

@orcinus The disappearing mouse pointer on the Mac client has been around for a while. You might want to look for an existing bug report on it.

As a workaround, I have found that you can make the pointer come back if you move to top of the screen and click on the global menu bar with the client's mouse/trackpad.

[brunovianarezende]

I've commented before about: 'Linux host to linux client @ (shift + 2) producing Ω instead'. This one is fixed for me. There is another one related with Mac that I'll try later.

[dbalabka]

Not sure is it related but seems version 1.8.3 have some changes in keyboard layout behavior. Now I get incorrect chars when use Windowse ENG(server) and MacOS RUS Phonetic(client). Example:

1. Press key ` and I got ` , but must ю
2. Press key = and I got =, but must ч

Here is debug log:

[2016-10-03T20:55:07] DEBUG2: msg from "Dmitrijss-MacBook-Pro.local": CNOP
[2016-10-03T20:55:07] DEBUG2: no-op from
[2016-10-03T20:55:08] DEBUG1: hook: 0x000000bb 0x800d0001
[2016-10-03T20:55:08] DEBUG1: hook: 0x06013dbb 0x800d0001
[2016-10-03T20:55:08] DEBUG1: hook: 0x07003dbb 0x800d0001
[2016-10-03T20:55:08] DEBUG1: event: Key char=61, vk=0xbb, nagr=0, lParam=0x800d0001
[2016-10-03T20:55:08] DEBUG1: new mask: 0x2000
[2016-10-03T20:55:08] DEBUG1: new mask: 0x2000
[2016-10-03T20:55:08] DEBUG1: onKeyUp id=61 mask=0x2000 button=0x000d
[2016-10-03T20:55:08] DEBUG1: send key up to "Dmitrijss-MacBook-Pro.local" id=61, mask=0x2000, button=0x000d
[2016-10-03T20:55:08] DEBUG2: writef(DKUP%2i%2i%2i)
[2016-10-03T20:55:08] DEBUG2: wrote 10 bytes
[2016-10-03T20:55:08] DEBUG2: writing secure socket:00000000023CEE70
[2016-10-03T20:55:08] DEBUG2: reading secure socket
[2016-10-03T20:55:08] DEBUG2: reading secure socket
[2016-10-03T20:55:08] DEBUG2: want to read, error=2, attempt=1
...
8] DEBUG1: hook: 0x000000c0 0x00290001
[2016-10-03T20:55:08] DEBUG1: hook: 0x060160c0 0x00290001
[2016-10-03T20:55:08] DEBUG1: hook: 0x070060c0 0x00290001
[2016-10-03T20:55:08] DEBUG1: event: Key char=96, vk=0xc0, nagr=0, lParam=0x00290001
[2016-10-03T20:55:08] DEBUG1: new mask: 0x2000
[2016-10-03T20:55:08] DEBUG1: new mask: 0x2000
[2016-10-03T20:55:08] DEBUG1: onKeyDown id=96 mask=0x2000 button=0x0029
[2016-10-03T20:55:08] DEBUG1: send key down to "Dmitrijss-MacBook-Pro.local" id=96, mask=0x2000, button=0x0029
[2016-10-03T20:55:08] DEBUG2: writef(DKDN%2i%2i%2i)

[dbalabka]

I have set MacOS as server for testing purspose to see what key code will be on Mac for same key. Here is debug log for ` key:

[2016-10-03T21:07:54] DEBUG1: onKeyDown id=1102 mask=0x0000 button=0x0033
[2016-10-03T21:07:54] DEBUG1: event: Key event kind: 11, keycode=50
[2016-10-03T21:07:54] DEBUG1: new mask: 0x0000
[2016-10-03T21:07:54] DEBUG1: onKeyUp id=0 mask=0x0000 button=0x0033
[2016-10-03T21:07:54] DEBUG2: checking clipboard
[2016-10-03T21:07:54] DEBUG2: flags: 0
[2016-10-03T21:07:55] DEBUG2: checking clipboard
[2016-10-03T21:07:55] DEBUG2: flags: 0
[2016-10-03T21:07:56] DEBUG1: event: Key event kind: 10, keycode=50
[2016-10-03T21:07:56] DEBUG2: modifiers: 00000000
[2016-10-03T21:07:56] DEBUG1: new mask: 0x0000
[2016-10-03T21:07:56] DEBUG1: onKeyDown id=1102 mask=0x0000 button=0x0033
[2016-10-03T21:07:56] DEBUG1: event: Key event kind: 11, keycode=50
[2016-10-03T21:07:56] DEBUG1: new mask: 0x0000
[2016-10-03T21:07:56] DEBUG1: onKeyUp id=0 mask=0x0000 button=0x0033
[2016-10-03T21:07:56] DEBUG2: checking clipboard
[2016-10-03T21:07:56] DEBUG2: flags: 0

[yurigoul]

What you press on the server keyboard is what you should get at the client.
This seems expected behavior to me

On 3 Oct 2016 20:01, "Dmitry Balabka" [email protected] wrote:

Not sure is it related but seems version 1.8.3 have some changes in
keyboard layout behavior. Now I get incorrect chars when use Windowse
ENG(server) and MacOS RUS Phonetic(client). Example:

1. Press key __ and I got __, but must _ю_
2. Press key _=_ and I got _=_, but must _ч_

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-251178608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa6BULZSasQVejDnewHJ2ZVmZlXmbks5qwUMSgaJpZM4DJe4x
.

[dbalabka]

@yurigoul it's not expected behavior to me, because I'm using two layout Cyrilic and Latin on server and on client in following ways:

1. Server ENG => Client ENG :+1:
2. Server ENG => Client RUS :+1:

below setups doesn't work for me, because of originaly described problem in this ticket above:

1. Server RUS => Client ENG :x:
2. Server RUS => Client RUS :x:

For Cyrilic I'm using phonetic layout and some keys are mappend in different way than Latin layout as I already described in https://github.com/symless/synergy/issues/4280#issuecomment-251178608

I guess the issue is that for some keys Server send(or Client use)scancode, but for some keys result char (https://en.wikipedia.org/wiki/Scancode). And this issue has been introduced in 1.8.3 version, because previous version was fine.

[yurigoul]

Then your problem should be in a different ticket is my guess - since this
adds another layer.

[email protected]
017681773842
www.AlienSaints.com

On Mon, Oct 3, 2016 at 10:15 PM, Dmitry Balabka [email protected]
wrote:

@yurigoul https://github.com/yurigoul it's not expected behavior to me,
because I'm using two layout Cyrilic and Latin on server and on client in
following ways:

1. Server ENG => Client ENG 👍
2. Server ENG => Client RUS 👍

below setups doesn't work for me, because of originaly described problem
in this ticket above:

1. Server RUS => Client ENG ❌
2. Server RUS => Client RUS ❌

For Cyrilic I'm using phonetic layout and some keys are mappend in
different way than Latin layout as I already described in #4280 (comment)
https://github.com/symless/synergy/issues/4280#issuecomment-251178608

I guess the issue is that for some keys Server send(or Client
use)scancode, but for some keys result char (https://en.wikipedia.org/
wiki/Scancode). And this issue has been introduced in 1.8.3 version,
because previous version was fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-251213707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa4lXjDl5rB2LX7ut8--oFpF4kjO0ks5qwWJggaJpZM4DJe4x
.

[yurigoul]

But what do I know, I am just a user :-)

[email protected]
017681773842
www.AlienSaints.com

On Mon, Oct 3, 2016 at 11:44 PM, Alien Saints [email protected] wrote:

Then your problem should be in a different ticket is my guess - since this
adds another layer.

[email protected]
017681773842
www.AlienSaints.com

On Mon, Oct 3, 2016 at 10:15 PM, Dmitry Balabka [email protected]
wrote:

@yurigoul https://github.com/yurigoul it's not expected behavior to
me, because I'm using two layout Cyrilic and Latin on server and on client
in following ways:

1. Server ENG => Client ENG 👍
2. Server ENG => Client RUS 👍

below setups doesn't work for me, because of originaly described problem
in this ticket above:

1. Server RUS => Client ENG ❌
2. Server RUS => Client RUS ❌

For Cyrilic I'm using phonetic layout and some keys are mappend in
different way than Latin layout as I already described in #4280 (comment)
https://github.com/symless/synergy/issues/4280#issuecomment-251178608

I guess the issue is that for some keys Server send(or Client
use)scancode, but for some keys result char (
https://en.wikipedia.org/wiki/Scancode). And this issue has been
introduced in 1.8.3 version, because previous version was fine.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-251213707,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa4lXjDl5rB2LX7ut8--oFpF4kjO0ks5qwWJggaJpZM4DJe4x
.

[XinyuHou]

Operating Systems

Client: MacOS Sierra 10.12

Server: Windows 10 (1607, 14393.321) x64

Synergy Version

1.8.4 stable

Steps to reproduce bug

You should have two keyboard layouts on server and client. English and Russian. Russian - PC on Mac.
Switch keyboard layout on server screen with mouse or Win+Space to ENG.
Switch keyboard layout on client screen to RUS.
Some keys will produce Russian characters but other will still be in English. Example: я -> z, ч -> x, в -> d but ц -> ц, к -> к. Full map of wrong characters (yellow is bad, green are good): http://take.ms/KLga8
Other info

When did the problem start to occur? When I upgraded to 1.8.4. I think the last version without this issue is 1.8.2. But I'm not confident.
Is there a way to work around it? No/Yes, you can change keyboard layout on server to RUS.
Does this bug prevent you from using Synergy entirely? No
If you switch keyboard layout of the server to the Russian it will work completely normal with both layouts.

[yurigoul]

I would open a separate case for this

[email protected]
017681773842
www.AlienSaints.com

On Wed, Oct 19, 2016 at 12:12 PM, Jerry (Xinyu Hou) <
[email protected]> wrote:

Operating Systems

Client: MacOS Sierra 10.12

Server: Windows 10 (1607, 14393.321) x64

Synergy Version

1.8.4 stable

Steps to reproduce bug

You should have two keyboard layouts on server and client. English and
Russian. Russian - PC on Mac.
Switch keyboard layout on server screen with mouse or Win+Space to ENG.
Switch keyboard layout on client screen to RUS.
Some keys will produce Russian characters but other will still be in
English. Example: я -> z, ч -> x, в -> d but ц -> ц, к -> к. Full map of
wrong characters (yellow is bad, green are good): http://take.ms/KLga8
Other info

When did the problem start to occur? When I upgraded to 1.8.4. I think the
last version without this issue is 1.8.2. But I'm not confident.
Is there a way to work around it? No/Yes, you can change keyboard layout
on server to RUS.
Does this bug prevent you from using Synergy entirely? No
If you switch keyboard layout of the server to the Russian it will work
completely normal with both layouts.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/symless/synergy/issues/4280#issuecomment-254771225,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALQEa_yzOi7B2titjJNRzLV1lG9vT7v4ks5q1e0CgaJpZM4DJe4x
.

[gamelaster]

I want to ask, is this issue solved already? I have same issue, the some keys (from Windows to OS X) is written wrong. I'm running under the old version, but if it's fixed already, I will buy a full version

[tenleftfingers]

Still an issue on two Ubuntu 16.04 64-bit machines. With both on Dvorak, I get garbage. If I set the client to use US it's okay. BUT if the client boots with US, it's still an issue. I have to switch to Dvorak and back to US - then it's okay.

[adeadman]

Marek, the issue is solved in the latest version (I'm also running Windows
10->OS X El Capitan).
tenleftfingers, that sounds like a separate issue, since you are able to
get it fixed by switching twice. You should open a new issue for that.

On Wed, Nov 2, 2016 at 6:06 AM, tenleftfingers [email protected]
wrote:

Still an issue on two Ubuntu 16.04 64-bit machines. With both on Dvorak, I
get garbage. If I set the client to use US it's okay. BUT if the client
boots with US, it's still an issue. I have to switch to Dvorak and back to
US - then it's okay.

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

[SanRudnev]

synergy-v1.8.6-rc1-d0db743 still has the issue described in #4065 . Is there any version available with some sort of a fix, even partial maybe?

[gamelaster]

@SanRudnev be sure you have same keyboard layouts on both OSes

[SanRudnev]

@GAMELASTER, I am. Both PCs are windows, both have EN + RUS. Only one combination works fine EN-EN, another 3 combinations don't work :(

[gamelaster]

@SanRudnev I have it same. Actually I know how the whole trouble works.
I will explain my trouble. I have:

Windows 10 Pro x64 (Server)

• English keyboard layout (Default layout)
• Slovakian keyboard layout

Macbook mid 2012 (macOS Sierra) (Client)

• Slovakian keyboard layout (Default layout)
• English keyboard layout

The keyboard on OS X is fine only, when the latest focused app on server have same keyboard layout as clients app (Well, this depends what settings you have, on my Win10 I have enabled to set custom keyboard layout per window, not globally, same on OS X). But anyway still layouts needs to be same on both platforms.

I see the way to solve this (really) annoying problem, and thats just "synchronise" the keyboard layouts. If keyboard layout doesnt exists, it will use one of mutual layouts. On Windows and OS X (Text Input Services API) it is possible. If I will got some time and luck to do that, I will send PR.

[SanRudnev]

@GAMELASTER I was pretty sure that server sends hardware keyboard key ids to a client, so both can have independent software layouts. Otherwise we have a problem with switching, let's say I have EN on server, when I move mouse to client window and type - it types in EN (as server sends in it), but how can I switch to RU or DE? If I press Ctlr-Shift on client, server will not change layout, client will, but that wouldn't affect what server sends.

[gamelaster]

@SanRudnev focus the server and change the last focused (foreground) window keyboard layout

[SanRudnev]

@GAMELASTER, that is something I'd like to avoid. I have 4 huge monitors and if I'm on far left monitor I wouldn't return back to far right to type one symbol in different language.

Currently when I press Ctrl-Shift on client PC, it changes its keyboard layout (server doesn't do that at the same time), ant I believe that is right thing to do. That doesn't help at all now because of the bug we're discussing, though.

[gamelaster]

Well, I hope it will be resolved soon, it's really annoying

[oliveira-rafa]

I had this issue today. I'm using a Synergy 1.8.7-stable version on server and client. The server is my Windows 10 desktop and the client is my windows 10 lenovo notebook. The funny thing is i started a VMware of Zorin OS linux and inside the linux on VMware the keyboard works perfectly. So i got back to windows on client and the keyboard started to work perfect again. I'm using brazilian portuguese as system language and english international as a input method on both windows systems and linux.

[nlyan]

See if v1.8.8-rc1 changes anything for you guys

https://symless.com/nightly?filter=fc3cc78

[SanRudnev]

@nlyan Thank you, but no - there is no difference. I've installed 1.8.8 you've sent on both client and server, rebooted both sides. The bug is fully reproducible.

Let me know if you need my help in debugging, I'd be glad to help.

[orcinus]

For what it's worth (just offering an additional data point), i haven't had this issue for many months now.

I'm running 1.8.3-stable-db9181b on a Mac (client), and 1.8.3-stable-db9181b on Windows (server). I don't intend to move from that build for as long as i don't have to :)

[zoh48gz04]

Hi there,
running Windows 7 Pro 64-bit as server and debian testing as client, both running 1.8.7 and have german-layout keyboards (qwertz+umlauts).
I'm having the same problem, but there were some wird things:
I _think_ to remember, that it worked perfectly after setting up for the first time.
Then it stopped working suddenly, I changed clipboard and drag and drop settings a few times and the keyboard-layout changed to US some times, after toggling these settings it eventually reverted to german without umlauts. Unfortunately I'm unable to reproduce this "stable", but maybe this is a hint for you?
Thanks for your work btw!
If I can help you out with debug info or something else please let me know.

[zoh48gz04]

OK, it seems I don't have to change anything. My notebook just reconnected it's ethernet and after that the keyboard layout of synergy's US again.

[kimgr]

Purchased and installed Synergy 1.8.7-stable today and this bit me immediately.

Server on Xubuntu14.04 and client on Windows 7.

[gamelaster]

@kimgr New version 2 (actually in beta) probably have it solved.

[SanRudnev]

@GAMELASTER just installed this one: https://symless.com/files/nightly/synergy-v2.0.0-cf-stable-3d3b7ca-Windows-x64.msi

No luck - the issue is still reproducible

[QuAzI]

Server: Windows 7 SP1 EN
Client: Linux Mint 17.3
Version: 1.8.8-rc1-fc3cc78 (and all other versions which I try to use at last year)

Windows (Server) | Linux (Client) | Status
-----------|-----------|--------------
En | En | Work
En | Ru | Work
Ru | En | Doesn't work
Ru | Ru | Doesn't work

When server use non ASCII language - alphabet, hotkeys with alphabet and some other keys doesn't work

synergy-mint17.3.log.txt
synergy-win7.log.txt

[sidex100]

Same: no Russian (Ru) language switch on client (server windows 7 x64, clien windows 7 x64)
Version: 1.8.8 on both server & client.
https://symless.com/files/nightly/synergy-v1.8.8-stable-c30301e-Windows-x64.msi

[lookcho]

Server: Windows 7U SP1, 64bit, keyboard layout - US international, 1.8.8-stable-25a8cb2
Client: Windows 10, 64bit, keyboard layout - UK, 1.8.8-stable-25a8cb2

A few observed problems:

1. server switched to Bulgarian, client to English , writing in client results in '???????????'
2. server switched to any language, client switched to Bulgarian - first key pressed switches the client to English.
3. CapsLock Active - pressing Alt+Shift does nothing (it is the hotkey for switching languages)

Will test it with the other OSes and tell if any of them behaves like that.

[vanowm]

Everyone watching this issue, use the "reaction" -> "thumb up" on the first post to add your voice, because devs are sorting issues by reactions to prioritize bugs.
Currently this issue is set to be resolved in v1.10 and we are still on v1.8!

Server: Windows 10 x64 1703 (build 15063.250), UAC on, 1.8.8-stable-25a8cb2
Client: Windows 7 x64 Sp1, UAC off, 1.8.8-stable-25a8cb2

Keyboard layout - US international

| Server | Client | Result|
|-------|-------|-------|
| EN | EN | Works |
| EN | RU | Doesn't work, client auto switches to EN after key press |
| RU | EN | Doesn't work, shows ??? |
| RU | RU | Doesn't work, shows ??? |

[dbalabka]

Synergy 2.0.0-beta4 still have this issue. Hope it will be fixed before stable release

[davidstosik]

Thanks for the info @torinaki! Honestly, I'm glad I didn't pay to get access to that beta...

Almost 3 years after reporting, I feel like there's no hope to see this issue fixed anymore...

[ehuott]

@davidstosik @torinaki

I gave up on the newer pay versions and fell back to older free versions a while ago. It solved the problem in my particular setup and I plan to stick to these versions for as long as I can.

I have correct keyboard mapping and working cut and paste with Synergy 1.3.1 on Mac OS X 10.11 (client) and Synergy 1.4.12 on Ubuntu 14.04 (server). Hopefully, these older versions will continue working with newer OSes.

For encryption, I use ssh and forward port 24800 (synergy) through the tunnel.

[orcinus]

1.8.8-stable on Windows + 1.8.3-stable on Mac OS seems to work fine for me.
Actually, haven't had any layout problems since 1.8.3, at least with this combo.

Is it just the Linux client that's screwed up now?

[nikez]

Swedish Keyboard layout on both server + client, issue still exists with 1.9.1-stable. Also tested with 2.0.12-beta.

Å Ä Ö doesn't type at all, rest of the keyboard works just fine (@ is at alt gr + 2)

Please consider escalating this issue.

Server

Windows 10 build 1803
Swedish Keyboard Layout - Physical and in Windows

Client

Windows 10 build 1607
Swedish Keyboard Layout - Physical and in Windows

Logs

[2018-05-23T10:25:30] DEBUG2: msg from "CLIENT1": CNOP
[2018-05-23T10:25:30] DEBUG2: no-op from
[2018-05-23T10:25:31] DEBUG1: hook: 0x000000dd 0x801a0001
[2018-05-23T10:25:31] DEBUG1: hook: 0x0601e5dd 0x801a0001
[2018-05-23T10:25:31] DEBUG1: hook: 0x0700e5dd 0x801a0001
[2018-05-23T10:25:31] DEBUG1: event: Key char=229, vk=0xdd, nagr=0, lParam=0x801a0001
[2018-05-23T10:25:31] DEBUG1: new mask: 0x0000
[2018-05-23T10:25:31] DEBUG1: new mask: 0x0000
[2018-05-23T10:25:31] DEBUG1: onKeyUp id=65533 mask=0x0000 button=0x001a
[2018-05-23T10:25:31] DEBUG1: send key up to "CLIENT1" id=65533, mask=0x0000, button=0x001a
[2018-05-23T10:25:31] DEBUG2: writef(DKUP%2i%2i%2i)
[2018-05-23T10:25:31] DEBUG2: wrote 10 bytes
[2018-05-23T10:25:31] DEBUG2: writing secure socket:000001ED3BE52B60
[2018-05-23T10:25:31] DEBUG2: reading secure socket
[2018-05-23T10:25:31] DEBUG2: reading secure socket
[2018-05-23T10:25:31] DEBUG2: want to read, error=2, attempt=1

[2018-05-23T10:27:14] DEBUG2: msg from server: DKDN
[2018-05-23T10:27:14] DEBUG2: readf(%2i%2i%2i)
[2018-05-23T10:27:14] DEBUG2: readf: read 2 byte integer: 65533 (0xfffd)
[2018-05-23T10:27:14] DEBUG2: readf: read 2 byte integer: 0 (0x0)
[2018-05-23T10:27:14] DEBUG2: readf: read 2 byte integer: 26 (0x1a)
[2018-05-23T10:27:14] DEBUG1: recv key down id=0x0000fffd, mask=0x0000, button=0x001a
[2018-05-23T10:27:14] DEBUG1: mapKey fffd (65533) with mask 0000, start state: 2000
[2018-05-23T10:27:14] DEBUG1: key fffd is not on keyboard
[2018-05-23T10:27:14] DEBUG2: writef(CNOP)
[2018-05-23T10:27:14] DEBUG2: wrote 4 bytes
[2018-05-23T10:27:14] DEBUG2: writing secure socket:0000021CB08A0F60
[2018-05-23T10:27:14] DEBUG2: reading secure socket
[2018-05-23T10:27:14] DEBUG2: reading secure socket
[2018-05-23T10:27:14] DEBUG2: want to read, error=2, attempt=1

[kontsevoy]

Happens with Synergy 1.10.0-stable when languages do not match between client/server:

MacOS (client) | Ubuntu 18.04 LTS (server) | Result
----------| ------------------------|------------
RU | RU | Works
ENG | ENG | Works
RU | ENG | Doesn't work
EN | RU | Doesn't work

When it doesn't work, I basically get random input when I type.