VNC Keyboard Mapping Mismatch

0

Background

I am using a VNC Viewer to connect from my local client Windows 10 Home to a remote mac OS X El Capitan host. Unfortunately, on my remote desktop the key-to-character mappings are scrambled.

My local and remote OS keyboard layouts are set to German QWERTZ. I've been using TightVNC Viewer 2.8.11 and TurboVNC Viewer 2.2.2. The connection information reads keyboard layout: 00000407.

Problem

Some keys on my local keyboard (mostly special characters, such as §$%&"?*Ä') don't match the characters typed on the host server. And, crucially, I don't seem to be able to type some characters, such as ([]'° at all. This is an issue, since I need them frequently, e.g. for programming.

When I switch, locally AND remotely, to US English QWERTY, the problem vanishes. This is an acceptable workaround for now. But in the long run, I'd like to be able to type the keys which are actually displayed on the physical keyboard in front of me, as my 'muscle memory' is used to do.

I supsect, that I am not the only one with this problem and that there must be some (elegant) solution for it out there. I'd be very grateful for any ideas or hints!

Further info

From what I have read, there are multiple levels to the problem: one is the difference between Windows and Mac in options/alt/control/alt gr etc keys to reach special characters. Another is the RFB protocol which apparently works well with some keyboard combinations, though not with others. See also: here, here, here and here.

I have attached the text which displays the characters typed on the remote server, when I press the keys on my German QWERTZ keyboard, one by one, from top row to bottom row, from left to right, holding down different additional keys like shift.

First Row

612345678906z normal 61äs457-90´-z Caps Lock <!ÄS$%/_)=´_< Shift " Control ,. üü++# Alt Gr

Second Row

qwertyuiopy+ normal qwertyuiop3* Caps Lock QWERTYUIOP§* Shift Control 2 < Alt Gr

Third Row

asdfghjklir3 normal asdfghjkl-fä Caps Lock ASDFGHJKL_Fä Shift Control Alt Gr

Fourth Row

,zxcvbnm,.ß normal ,zxcvbnmööß Caps Lock :ZXCVBNMÖÖ? Shift Control Alt Gr

Dendron

Posted 2019-07-20T15:23:53.660

Reputation: 1

1This is going to be an ANSI/ISO difference, which I cannot test. I have only ISO & no QWERTZ. Generally Win & Mac do a very poor job of translating 'specials' Macs are reasonably consistent, Win is a s***-fest. Macs don't use alt/gr at all [in fact all that does is kills the dead-keys.] Win's dead-keys are handled in a different way & in fact aren't 'dead' at all, they depend on key-map - horribly unpredictable. On Mac, for é type alt/e then e. On Win type ' then e [if keymap is international]. What you need is a VNC app that knows how to deal with this, cross-plat. You can't hack it yourself. – Tetsujin – 2019-07-20T16:46:04.817

@Tetsujin Thanks for your comment! I was thinking exactly the same thing. This is why I tried TurboVNC 2.2.2, which is supposed to contain the QEMU extension to the RFB protocol. From what I understand, by sending keycodes instead of keysyms, the QEMU extension is supposed to bridge character mappings across platforms. Unfortunately, for me it produced almost exactly the same results as with TightVNC. So, I'm wondering: do I have to enable the QEMU extension separately within TurboVNC or is there a different approach altogether?

– Dendron – 2019-07-20T19:00:46.717

I'm honestly not sure. I usually remote from Mac to Win & have learned to get along with the Win remote set to US International, to give me the dead-keys, even though my 'native' keyboard is UK – Tetsujin – 2019-07-21T06:40:23.670

No answers