0

I figured the easiest way for me to write diacritics was a US keyboard and the compose key. It works natively on Linux and I installed WinCompose on my Windows 10 machine to make my writing experience consistent accross platforms. It works fine.

I have set up a Synergy 1 server on my Linux machine (Ubuntu 18.04 LTS) to remote control my Windows 10 machine. It works, but when I write text on the Windows 10 screen with the Linux machine's keyboard, diacritics are no longer merged with ASCII characters: instead of Ç, I get ,C.

I take it WinCompose listens to hardware key presses while Synergy sends software key codes, so the former can't pick up on them, or something along those lines, but can you confirm it? And if it is like so, what could I do to make this setup work the way I want?

This question might be a clue

geoffrey
  • 173
  • 10
  • Maybe you can investigate what characters are actually appearing. There is no diacritical mark here `,C` That is comma(0x2C) followed by C(0x43). And when you write `Ç` There is a single character there, utf-16 unicode 0xC7. (charmap and ms word show the utf-16 unicode code. In word put the cursor after a character and do alt-x). An example of two separate characters one a letter one a diacritical mark would be `אֻ`. What if you copy and paste that character from charmap? – barlop Mar 02 '19 at 02:20
  • what if you copy and paste that character from charmap? – barlop Mar 02 '19 at 02:22
  • The cedilla is a diacritic in the linguistical sense. When I type the following sequence `compose` `,` `C` it must output the character `Ç`. It works with a keyboard plugged in, it doesn't work through Synergy. What WinCompose does to take `,` and `C` as inputs and output `Ç` is probably important to understand how the two different setups have different behaviours, but whether the character `Ç` is a combined character or a precomposed character in UTF-16 probably is too low level to be relevant to the question. – geoffrey Mar 02 '19 at 15:36
  • Copy and Paste works fine – geoffrey Mar 02 '19 at 15:37
  • So it's not a display issue(which is a better way of saying what you descrbe as 'merging'). i.e. It's not that. Something is converting the character you want(C with mark on it), into two characters, a comma with C. Maybe you can pinpoint exactly which software program is doing it. if a program can display the thing fine i.e. shown with copy/paste then the program you are copy/pasting into supports unicode characters – barlop Mar 02 '19 at 15:43
  • some have suggested that wincompose has thsi kind of issue https://bugs.launchpad.net/zim/+bug/1629364 also https://github.com/samhocevar/wincompose/issues/235 try the latest wincompose version though it may not be much better. Looks like work on this problem/bug is quite current so try the latest version – barlop Mar 02 '19 at 15:46
  • I have the same issue with every application I have used so far. It's really as if WinCompose were not intercepting key presses coming from synergy. I don't know what Synergy does or if it emulates a peripheral at all. I see multiple keyboards in my peripherals list but this number doesn't change when I stop the server and reload the list, but I can't be sure it's an evidence (maybe there is a cache or something, what do I know) – geoffrey Mar 02 '19 at 16:02
  • what makes you think synergy has anything to do with this? have you tried synergy without wincompose and then seen this problem? – barlop Mar 02 '19 at 16:07
  • I really don't think it has anything to do with unicode characters support : I have both Synergy running and a keyboard directly attached right now. I'm going to do the same combination of keys : `'e` (this was Synergy) `é` (this was the physical keyboard). I just typed `compose` `'` `e`. The compose key is assigned to Ctrl right – geoffrey Mar 02 '19 at 16:10
  • what is the compose key, do you have a keyboard like this https://www.computerhope.com/jargon/c/compose-key.jpg ?! I've never heard of the compose key before, and only found this on googling now. – barlop Mar 02 '19 at 16:12
  • OK I just assigned the compose key to Ctrl left in the WinCompose settings and it works, so the problem was that WinCompose doesn't recognise when I press Ctrl right with Synergy. Is it possible Synergy emulates a keyboard with a different layout than the one I am physically using? – geoffrey Mar 02 '19 at 16:12
  • You can choose what key is your compose key. – geoffrey Mar 02 '19 at 16:13
  • Can you please report a new issue on GitHub? I’ll gladly try to find a fix for that problem. https://github.com/samhocevar/wincompose/issues – sam hocevar Mar 02 '19 at 23:08
  • At this stage I think it is clear it is not a WinCompose issue. You will find additional informations in my answer. – geoffrey Mar 03 '19 at 00:14

2 Answers2

1

unfortunately, this is not an answer, sorry.

I am facing exactly the same problem than you, for years now, and still in hope to find a fix... I have contacted guys in Synergy, posted in Synergy forum, WinCompose forum. But no valuable answer.

In my config :
- Linux machine (synergy server), QWERTY layout and Compose key enabled (Right-Win)
- Windows machine (synergy client) where I need to write in French. WinCompose is enabled.

I concur with your analyze about HW key signal vs. SW key code - it makes me think of the idea behind many anti-keylogger solutions : they offer a virtual keyboard, to delude keyloggers which are expecting HW key strokes.

You ended with a workaround (insert key) which comes with some cost... :/ I mean, this is not convenient at all, as I am using this key for other purpose. And I could not have decided on another key to declare in WinCompose...

So, instead, I have opted for other alternatives in Windows, typically AutoHotkey scripts (there are plenty of them on the Web) in order to :
- cycle through accented characters : e.g. you enter e then you can cycle through é è ê ë ₑ ₔ € ε with one special key-stroke.
- enter a special sequence which will be automatically converted in accented character : e.g. you enter ~'e and it will be recognized and converted into é by a script running in background...

I hope this will be dealt with by WinCompose and Synergy teams, at some point.

Cheers.

Ra0
  • 31
  • 2
  • Thanks for the alternative workarounds. I have also tried using my bluetooth keyboard, which has multiple bluetooth outputs, in a KVM switch fashion. It's not instantaneous (about 2 seconds) but the typing experience is better and it doesn't affect the clipboard sharing feature. When I wanted to go back and forth quickly, I left it on the server and only switched it to the client when I needed to type diacritics. It works on paper but I was sometimes confused about which output was active and I had to assign a different compose key on the laptop to accommodate layout differences. Not perfect. – geoffrey Mar 28 '19 at 11:50
0

It is not the magical solution I was expecting but it is an answer nonetheless: WinCompose was actually not detecting the compose key because it was not sent.

This key was assigned to Ctrl Right but, when I press Ctrl Right on the Linux machine's keyboard, it is not passed through Synergy. A simple test such as this one shows that pressing this key with this setup does not even trigger a keydown event on the Synergy client (it works on the server of course, and it doesn't work any better on the client when WinCompose is disabled).

AltGr doesn't work either and PrtSc (Print Screen) is misinterpreted as Alt Left, which leads me to think it is a layout issue on the Synergy side because the Linux machine is a Lenovo Thinkpad E480, which has its PrtSc key placed next to the Ctrl Right key.

Synergy allows to remap some modifier keys, but does not distinguish between left and right.

I decided to assign the compose key to insert, but I will gladly accept a better answer addressing the layout issue.

geoffrey
  • 173
  • 10