Problematic keys when connecting from Mac to KDE on CentOS

[TomasM]

Hi,

When connecting to CentOS server (KDE) from my Mac using NoMachine (also KDE) I am struggling to get a match between my Mac keyboard and what NoMachine gives me.

I would be happy if I could regain <> from left of the z key and $ from shift+4. Right now they are mapped to §, ° and ¤ respectively.

I have searched the forum, I have tried different setxkbmap options, I have tried using the KDE GUI, but all that happens is that I get more confused.

My setxkbmap -print looks like this:

xkb_keymap {
xkb_keycodes  { include “evdev+aliases(qwerty)” };
xkb_types     { include “complete”      };
xkb_compat    { include “complete”      };
xkb_symbols   { include “pc+se(mac)+inet(evdev)+level3(lwin_switch)”   };
xkb_geometry  { include “pc(pc104)”     };
};

Any clues would be highly appreciated.

Thanks,
Tomas.

(using Workstation 7.7.4, virtual display, CentOS 7, KDE+Gnome+fvwm)

[Britgirl]

Can you show me the output of xmodmap -pke? What does xev utility show when the problematic keys are pressed?

[TomasM]

Hi Britgirl,

Many thanks for your answer. Yesterday I found that it is related to the external keyboard (Logitech MX Keys for Mac). When I use the MBP keyboard, all is fine. Still a problem and grateful for any assistance. A reminder, partly to myself, both keyboards work when writing on the mac display (like this text), it is just in the NoMachine Linux environment.

When I use the internal keyboard and press (and get) < 

KeyPress event, serial 40, synthetic NO, window 0x5200001,
root 0x114, subw 0x0, time 4016131838, (109,89), root:(109,112),
state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
XLookupString gives 1 bytes: (3c) “<”
XmbLookupString gives 1 bytes: (3c) “<”
XFilterEvent returns: False

When I use the external keyboard and press the < key (and get §):

KeyPress event, serial 40, synthetic NO, window 0x5200001,
root 0x114, subw 0x0, time 4016229917, (55,105), root:(682,887),
state 0x0, keycode 49 (keysym 0xa7, section), same_screen YES,
XLookupString gives 1 bytes: (a7) “§”
XmbLookupString gives 1 bytes: (a7) “§”
XFilterEvent returns: False

If I do the same sequence using a VNC session,  I get the following, first with the built-in keyboard:

KeyPress event, serial 40, synthetic NO, window 0x1600001,
root 0x395, subw 0x0, time 4016999651, (74,50), root:(563,463),
state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
XLookupString gives 1 bytes: (3c) “<”
XmbLookupString gives 1 bytes: (3c) “<”
XFilterEvent returns: False

And with the external keyboard (VNC, pressing <)

KeyPress event, serial 40, synthetic NO, window 0x1600001,
root 0x395, subw 0x0, time 4017265012, (61,108), root:(550,521),
state 0x0, keycode 94 (keysym 0x3c, less), same_screen YES,
XLookupString gives 1 bytes: (3c) “<”
XmbLookupString gives 1 bytes: (3c) “<”
XFilterEvent returns: False

I attached the output of the xmodmap command.

Any clues?

Thanks again,
Tomas.

Attachments:

1. keys_mac.txt

[Britgirl]

Just a quick update on this. We decided to order a Logitech MX Keys for Mac to investigate, which we are in the process of doing now.

[Tor]

Hi Tomas. Do you use Karabiner or another keyboard customizer on macOS?

[TomasM]

@Britgirl: Thanks for the update and effort!

@Tor: No. Keys work fine on MacOS but differently when using NoMachine.

 

Regards,
Tomas.

[Britgirl]

TomasM, please check your inbox for emails from us 🙂

[Britgirl]

TomasM, just to let you know we are analysing the content you sent us.

[pevoz]

Hello,

I’m experiencing the exact same problem. The keymapping correctly works on a [removed] VM (ubuntu), but not on a remote Ubuntu accessed via NoMachine.

I’m using NoMachine 7.9.2 on macOS 12.3.1 on Apple M1 Pro. I also have Karabiner installed, but this does not seem to have an influence.

[Britgirl]

We haven’t been able to reproduce this behaviour, so we ask users who were encountering this issue to update to the latest 8 and open a new topic if the problem is still there, so that we can start a new investigation. This topic is going to be closed.

[Author]

Posts