search

symless / synergy-core

Open source core of Synergy, the cross-platform keyboard and mouse sharing tool (Windows, macOS, Linux)
https://symless.com/synergy
Other
10.16k stars 3.62k forks source link

International keyboard support #5

Closed nbolton closed 9 years ago

nbolton commented 9 years ago

Imported issue:

h2. Version 2 requirement

Version 2 must have full international keyboard support; non-us keyboard input in version 1 was unreliable. We may be able to enforce this with unit/integration tests.

h2. Original bug report

What steps will reproduce the problem?

  1. Switch to non-US layout (e.g. RU)
  2. Type a word

What is the expected output? What do you see instead?
layout gets switched back to US and the word is in english letters

What version of the product are you using? On what operating system?
Synerfy 1.3.1 windows XP on both comps

Please provide any additional information below.

nbolton commented 9 years ago

Synergy 1.4.16

Server is Windows 8.1, Keyboard is Japanese 106 key. Client is Mac OS X 10.9.4

Incorrect punctuation inserted (Mac thinks the keyboard is US layout)

Ideally I should be able to go into OS X keyboard properties and select the JIS layout - but since the Mac is headless, the settings button does nothing, and none of the pulldown lists shows Japanese/JIS as available.

Not sure what needs to happen for this to work correctly.

nbolton commented 9 years ago

Great work you've done with synergy, the shared clipboard is a great feature, but supporting only US keyboards is a terrific limit, because of this missing feature and bug #2832 I can't share the keyboard.

Would be nice to have a way for the user to customize the key mapping between clients and server (there is already? I found nothing), in the configuration file if possible, or if it is too complex for a configuration file with a script hook would be nice (something like lua or angelscript, or even a native plugins). Please, I would donate again in order to get it working.

steevesaustin commented 9 years ago

Hi, I got the same issue here.

I’m using the following config :

The keymap is completely different the server and the client for example when I type on the numbers line :

Server : @&é »’(§è!çà Client : éèeeùùç@<e&c<qà)

Do you have any idea when this keymap problem will be fixed ? cause in my case Synergy is useless without this :(

ngladitz commented 9 years ago

I've been told by synergy help desk that this issue also pertains me.

In my case I'm running:

All three run Synergy 1.5.1, have a German keyboard attached and German keyboard layout configured: PC: http://en.wikipedia.org/wiki/German_keyboard_layout#mediaviewer/File:KB_Germany.svg Mac: http://upload.wikimedia.org/wikipedia/commons/1/10/2007_09_30_de_Apple-Tastatur.jpg

Integration seems to mostly work, except for sequences involing the Alt Gr modifier.

Typing Alt Gr + ß on the Server correctly produces \. The same sequence on the Windows Client incorrectly produces ß (as if Alt Gr were not pressed). On the OS X Client the sequence produces 7 (which I can't explain).

goranche commented 9 years ago

I've been sent here by the help desk as well... :smile:

I'm running OS X Yosemite on both the server (a retina MBP) and the client (mac mini), using a trackpad and a slovene keyboard on the server.

the issue I'm facing is that 1 single key on my keyboard is behaving like a different one. pressing alt (option) while using that one key makes it behave like normal (and the other one as the first)

otherwise it seems to work quite nicely :+1: well worth the "huge" amount I paid for it :wink:

I didn't realise synergy was open source (still worth the money, though), but now that I do, I'll take a look at the source and try to find the issue... kind of sounds like a simple mapping issue to me (in my case, of course, not sure about the others)

SteveTWhitehouse commented 9 years ago

When using the USA International (with dead keys) keyboard on Fedora 15 ( 2.6.35.14-106.fc14.i686) (Synergy server running here)

the following characters type correctly on my Linux workstation, but not on my Windows laptop Synergy client:

Linux;

keystroke= ` (+) a (=) á

' a (=) á

Windows:

Pressing this key twice: ' does not display anything on the Windows client. All of the other deadkeys seem to work fine.

I can use my laptop keyboard to type this character: ' (single quote character on the double quote " key. The double quote character does not display nor work properly either.

I noticed that when I have multiple keyboards on my laptop, the layout switches to the layout that is selected on my Linux desktop where Synergy server is running.

So two separate issues (it seems)

  1. The Synergy server keyboard is the keyboard map that is used when typing on the client (working as designed I think)
  2. The keyboard does not work properly when typing on the client for certain keys even though it works fine on the server.
nsaintarnaud commented 9 years ago

There is apparently a lot of interest for international keyboard support - hardly surprising since the US is about 4% of the world population.

I see 3 different classes of issues:

  1. with keyboard layouts that share many keys with the US keyboard (British, Canadian French, Swedish, Turkish, French, German), the keys that are the same between the two layouts work fine - giving a false sense that the product is working - but the keys that are different get garbled - even more so for dead keys (like accents, where one types the accent dead key first and then the letter, so two keystrokes for one displayed letter, e.g. ^ then e makes ê - those get displayed as two characters like ùe by Synergy); punctuation also gets garbled, and Synergy is mostly unusable.
  2. for keyboard layouts that are completely different from the US (e.g. Cyrillic, Arabic), the output on the remote screen is completely gargled and the product is unusable.
  3. other issues linked to modifier keys, e.g. altGr

Some related open issues, in addition to the multitude mentioned above:

Case 1 British: https://github.com/synergy/synergy/issues/3961 Swedish: https://github.com/synergy/synergy/issues/4214 Turkish: https://github.com/synergy/synergy/issues/4164

Case 2: Arabic: https://github.com/synergy/synergy/issues/4088

... life will be good with international support!

nsaintarnaud commented 9 years ago

All international users please cast you vote for issue #5 (this issue) when you donate! https://synergy-project.org/premium/?vote

bbrdaric commented 9 years ago

Hello,

I am also affected by this bug. I have Croatian keyboard and Windows 8.1 x64 Pro (host) and Mac OS X 10.10 (client) and I cannot type characters that need Alt Gr modifier.

You can find more about South Slavic Latin keyboards here http://en.wikipedia.org/wiki/AltGr_key#South_Slavic_Latin

Please make possible that host OS is controlling keyboard layout.

davidstosik commented 9 years ago

Hi, similar issue here, with a weird setup, I'll admit.

Server:

Client:

I tried multiple keyboard layouts on Mac OS, with no good result. Also tried to create a keyboard with Ukelele, but it all goes crazy: looks like Ukelele reads various keyboard key inputs as the same key on its virtual keyboard ; for example, two different keys on my server-side Ducky Shine3 (the "5 | %" key, and the "[ | {" key) result in the same character '5' printing on the client's screen.

Obviously, this is not the most common setup you could find out there, but somehow, I think that Synergy could handle this kind of problem a lot better. I realize that bringing this now would require a lot of work, but I would love to see some solution... Right now, Synergy is basically useless for me.

myss commented 9 years ago

I have a Synergy server on Windows 7, using a Belgian Azerty keyboard layout (see http://en.wikipedia.org/wiki/AZERTY#mediaviewer/File:Belgian_pc_keyboard.svg).

I have a synergy client on OS X 10.9.5. I use a "turkish qwerty pc" layout with it as default. It also has the belgian AZERTY layout available.

If I set the belgian layout current on MAC:

If I set the "turkish qwerty pc" layout current on MAC:

As suggested somewhere, I have added "English - US" keyboard on Mac, removed all other keyboard layouts and did a restart. The result is not better:

It was suggested to use a US keyboard on the server as a workaround. But that is not an option for me.

myss commented 9 years ago

But there is no problem if I make OS X the server and windows the client. Also, I see that I receive key events faster. When server=Windows and client=OSX, it felt like I was using remote ssh.

Edit: I was too early. AltGr is not sent correctly from Mac to Windows.

The used layout is this: http://en.wikipedia.org/wiki/AZERTY#mediaviewer/File:Belgian_pc_keyboard.svg If I type AltGr+2, I get a '@' on OSX (as expected), but I get nothing on Windows. If I type Ctrl+Alt+2, I get a '2' on OSX (don't know why), and I get '@' on Windows. So, the workaround is to use Ctrl+Alt combination on Windows. The situation is still acceptable for me.

nbolton commented 9 years ago

I feel that this issue is too vague to "solve", we need to approach this by opening issues on a more granular level by identifying specific layout and/or key code support.

3dbloke commented 9 years ago

As per my email today to the Synergy Helpdesk and the prompt reply I received, here's my own experience of this problem:

I'm in the UK and use a standard UK keyboard config on my machines.

The set up:

Keyboard mapping of some keys is incorrect on the client.

Examples: @ ---> q

---> \

" ---> @ £ ---> #

This is pretty much what I'd expect if used a U.S. locale and keyboard mapping stand-alone on any of my systems.

I get similar problems when the client is a PC running Ubuntu Studio. Note that in Windows 7 on the same PC, as a Synergy client, the characters map correctly. This suggests it's a problem with the client.

The Raspberry Pi and Ubuntu Studio are set up with the correct UK locale and keyboard mappings. They work fine with their own keyboards.

It would be helpful to have some mention of this known issue in the FAQ.

--Thomas.

nbolton commented 9 years ago

@3dbloke Would you mind raising a specific bug for this? We closed this issue because its too generic to solve.