Keyboard mapping issues with 2.2.80 alpha

Thats for turbovnc, great stuff!

I'm using the beta version as I need a terminal services like solution for turbovnc and that works great.

It seems there are some problems with keyboard mappings(or I'm doing something wrong) in a few scenarios:

I connect to my iMAC screens with nomachine and then use turbovnc to get to an internal turbovnc server. What happens is that I click out of the turbovnc window and then back in turbovnc does not accept any keys anymore. It works first time I connect with nomachine and open the mac turbovnc client virtual desktop session but I if get click out of that window to use my mac for something else and then return to the turbovnc window no more keys get forwarded.
Keys are not mapped correctly when connected to a turbovnc virtual desktop and then accessing a novnc session within it.
The arrow keys are not doing what they suppose to do, if I press down arrow it considers it an "Enter", nothing happens if I press up/left/right. This happens while using Linux and Mac turbovnc clients. In this scenario I'm accessing VM consoles (novnc based)within a Proxmox cluster if its relevant in any way.

I understand this version is beta but I find the ssh based session launch very useful as we have multiple users connecting to the turbovnc server for linux virtual desktops with gl acceleration. Is there something that I can do to fix the mappings or if its a bug maybe I contribute for a fix in some way?

Cheers!

2.2.80 is still alpha, not beta yet.

Nothing has changed in the key mapping code between the alpha version and the stable version, so whatever issue you're experiencing is probably in 2.2.6 as well. But I need a better understanding of exactly what you're doing, because it sounds like a bit of a Rube Goldberg device. I don't know what you mean by "connect to my iMAC screens" or "use turbovnc to get to an internal turbovnc server" or "open the mac turbovnc client virtual desktop session." That's all pretty loose terminology, to be frank.

Thanks for replying, thats fair, I'll try to do a better job explaining, its a lot simpler that what it seems.

I use an Imac at work that I have nomachine installed on it to connect to the osx desktop. From my imac, using turbovnc ,I connect to a linux virtual desktop environment with gl enabled. When I connect to my work imac using nomachine from my laptop while I'm home it seems the keyboard connection is lost if i click out of the turbovnc window and then back on. I have to close the turbovnc window and then reconnect to my turbovnc server to make the keyboard working again inside the turbovnc window.
On the second scenario, when using turbovnc from my imac to connect to my linux virtual desktop and from there to connect to a novnc session over firefox the keyboard mapping is wrong while typing inside the novnc window. This does not happen if I connect to the same novnc session directly from the imac and not trough the turbovnc session.

I hope this is better if not I can post a video on youtube with how this behaves.

Server config: OS: CentOS7

/etc/turbovncserver.conf
## These settings are the default.  Uncomment and edit to change.
#
# $geometry = "1240x900";
# $depth = 24;
# $desktopName = "TurboVNC ($ENV{USER})";
# $vncClasses = "/opt/TurboVNC/java";
# $vncUserDir = "$ENV{HOME}/.vnc";
# $fontPath = "";
# $securityTypes = "TLSVnc, TLSOtp, TLSPlain, X509Vnc, X509Otp, X509Plain, VNC, OTP, UnixLogin, Plain";
$securityTypes = "Plain, UnixLogin, OTP"
# $generateOTP = 0;
# $autoLosslessRefresh = 0.0;
$enableHTTP = 0;
# $wm = "";
$useVGL = 1;
# $autokill = 0;
$pamSession = 0;
$multiThread = 1;
$numThreads = 8;
# $serverArgs = "";

## Uncomment this to use the X font server by default, rather than a static
## font path.
#
# $fontPath = "unix/:7100";

## Here is another example of setting the font path:
#
# $fontPath = "/usr/lib/X11/fonts/misc/"
# $fontPath = "$fontPath,/usr/lib/X11/fonts/75dpi/";

## You might wish to create the TurboVNC user directories under /tmp, to
## ensure that VNC passwords are always kept on the local filesystem.  To do
## that, uncomment the line below.  Note that in this case, Xvnc will search
## for the .Xauthority file in this same directory by default, and the TurboVNC
## startup script will be stored in $ENV{HOME}/.turbovncstartup instead of in
## $vncUserDir/xstartup.turbovnc.
#
# $vncUserDir = "/tmp/$ENV{USER}-vnc";

## These settings are the default.  Uncomment and edit to change.
#
# $passwdFile = "$vncUserDir/passwd";
# $x509CertFile = "$vncUserDir/x509_cert.pem";
# $x509KeyFile = "$vncUserDir/x509_private.pem";

/etc/turbovncserver-security.conf

# Uncomment the following to turn on the user access control list whenever
# the PAM User/Password authentication method is used.
# (Default: user ACL is disabled)

enable-user-acl

# This specifies the maximum desktop size for all TurboVNC sessions started on
# this host.  If a user attempts to start a session with a larger geometry than
# this or to use remote desktop resizing to increase the desktop size to a size
# larger than this, the desktop size will be clamped to this width/height.

max-desktop-size = 5140x4432

# This specifies the maximum idle timeout (in seconds) for all TurboVNC
# sessions started on this host.  The idle timeout is the amount of time that
# a TurboVNC session can remain idle (with no VNC viewer connections) before it
# will automatically exit.  If this value is set to a number greater than 0,
# then all TurboVNC sessions on this host will use this idle timeout value by
# default, and the user will only be allowed to override it with a lower value.

#max-idle-timeout = 86400

# Uncomment the following to globally disable the automatic sending of
# clipboard changes to TurboVNC sessions from their connected viewers.
# (Default: clipboard receiving is allowed)

#no-clipboard-recv

# Uncomment the following to globally disable the automatic sending of
# clipboard changes from TurboVNC sessions to their connected viewers.
# (Default: clipboard sending is allowed)

#no-clipboard-send

# Uncomment the following to globally disable the built-in HTTP server in all
# TurboVNC sessions started on this host.

#no-httpd

# Uncomment the following to globally disable creating/opening PAM sessions in
# all TurboVNC sessions started on this host.

#no-pam-sessions

# Uncomment the following to globally disable inbound remote connections to all
# TurboVNC sessions started on this host.  This effectively forces SSH
# tunneling to be used for all inbound TurboVNC connections.
# (Default: inbound remote connections are allowed)

#no-remote-connections

# Uncomment the following to globally disable remote desktop resizing.
# (Default: remote desktop resizing is allowed)

#no-remote-resize

# Uncomment the following to globally disable the ability to make reverse
# VNC connections.
# (Default: reverse connections are allowed)

#no-reverse-connections

# Uncomment the following to globally disable X11 TCP connections to all
# TurboVNC sessions started on this host.

#no-x11-tcp-connections

# Set pam-service-name to the name of the PAM service that you will use to
# to process PAM User/Password authentications from TurboVNC.  This service
# name typically corresponds to a file in /etc/pam.d or to one or more lines in
# /etc/pam.conf.
# (Default: turbovnc)

pam-service-name = login

# Set the following to a colon-separated list of permitted TLS cipher suites
# for the TLS* and X509* security types.  (Run 'openssl ciphers aNULL' for a
# list of possible options for the TLS* security types, and 'openssl ciphers'
# for a list of possible options for the X509* security types.)  This directive
# also controls the order in which the cipher suites are advertised to the VNC
# viewer.  This directive is ignored if the TurboVNC Server was built with
# GnuTLS rather than OpenSSL.
# (Default: allow any cipher suite supported by the host's OpenSSL
# implementation)

#permitted-cipher-suites =

# Set the following to any combination of "TLSVnc", "TLSOtp", "TLSPlain",
# "TLSNone", "X509Vnc", "X509Otp", "X509Plain", "X509None", "VNC", "OTP",
# "UnixLogin", "Plain", or "None", separated by commas (security types are
# case-insensitive.)  If the following directive is enabled and a particular
# security type is not listed in it, then users cannot enable that security
# type by using Xvnc command-line arguments.  This directive also controls the
# order in which the corresponding authentication capabilities are advertised
# to the VNC viewer.  See the man pages and User's Guide for more information.
# (Default: TLSVnc, TLSOtp, TLSPlain, TLSNone, X509Vnc, X509Otp, X509Plain, X509None, VNC, OTP, UnixLogin, Plain, None)

#permitted-security-types = TLSVnc, TLSOtp, TLSPlain, X509Vnc, X509Otp, X509Plain, VNC, OTP, UnixLogin, Plain

# This specifies the length of the key, in bits, that the TurboVNC Server will
# generate for any of the TLS* (anonymous TLS) security types.
# (Default: 2048)

#tls-key-length = 2048

I use an Imac at work that I have nomachine installed on it to connect to the osx desktop. From my imac, using turbovnc ,I connect to a linux virtual desktop environment with gl enabled. When I connect to my work imac using nomachine from my laptop while I'm home it seems the keyboard connection is lost if i click out of the turbovnc window and then back on. I have to close the turbovnc window and then reconnect to my turbovnc server to make the keyboard working again inside the turbovnc window.

Why can't you just connect directly to your Linux virtual desktop from your home laptop using TurboVNC? (NOTE: even if the Linux VM is only visible from the Mac, you can still make a TurboVNC connection through the Mac to the VM, using the Mac as an SSH gateway.) No one has reported such issues with TurboVNC alone, and I personally use the TurboVNC Viewer on macOS on a daily basis with no issues. I can't help but conclude that the multi-level connection using NoMachine is causing this problem.

On the second scenario, when using turbovnc from my imac to connect to my linux virtual desktop and from there to connect to a novnc session over firefox the keyboard mapping is wrong while typing inside the novnc window. This does not happen if I connect to the same novnc session directly from the imac and not trough the turbovnc session.

Once again, I don't understand the purpose of this multi-level connection. Why not just connect directly to the machine running the TurboVNC session?

If you can reproduce any of these issues using TurboVNC alone, then I will investigate.

Thanks for your time again. I understand the temptation to ask why using nomachine at all but the answer is a bit more complicated. My workflow is a bit complex and requires that I use my mac and linux virtual desktop in the same time. Theres a lot of copy paste going in between the 2 machines as I need to feed some data in some linux only apps. Another issue is that nomachine is working a lot better with 160ms+ latency over wan + I require audio for video playback at times which turbovnc does not provide yet, looking forward for that in the future.

I've tested tigervnc in the same context and seems theres no keyboard issues there. If you dont have time thats understandable, the only reason I've open the ticket is because I saw it working normally with tigervnc, but i dont have gl with tigervnc :/

For the second issue, I'll set up a new environment that I connect directly to the turbovnc server and see if I get the same problems interacting with novnc.

So you couldn’t use NoMachine to connect to the Mac and TurboVNC to connect to Linux? It should be possible to copy and paste between those two viewers.

There’s very little I can do without the ability to reproduce the issue, and it would take me many unpaid hours to duplicate your unique computing environment. If you manage to reproduce the issue without the multi-level connection, then I’m happy to investigate it.

Some additional technical notes:

TigerVNC uses a different keyboard mapping mechanism than TurboVNC does. TigerVNC sends raw key codes (which correspond to physical keys on the keyboard) from the viewer to the server, so key mapping (the non-reversible conversion from key codes to key symbols) is done on the server side. TurboVNC uses the traditional VNC mechanism, whereby key mapping is done on the client side and key symbols are sent from viewer to server. I am in the process of implementing server-side key mapping in TurboVNC 3.0. However, no issues have been reported with TurboVNC's existing client-side key mapping mechanism, other than some minor issues with "dead keys" (which are used to generate accents on certain non-U.S. keyboard layouts.) I mention this because it could explain why TigerVNC works and TurboVNC doesn't.
If you have multiple keyboard layouts installed on macOS, sometimes the keyboard layout can switch if you switch windows. If System Preferences-->Keyboard-->Input Sources-->Show Input menu in menu bar is checked, then there should be an icon in the menu bar indicating which keyboard layout is current. If you don't have multiple keyboard layouts installed on macOS, then ignore this bullet point.
In order to support drawing tablets, the Mac TurboVNC Viewer taps into the macOS event handler by default. I mention this because the tablet event monitor is automatically disabled when the TurboVNC Viewer window loses keyboard focus and automatically re-enabled when the window gains focus. Maybe that is somehow interfering with something in NoMachine. It would be worth trying to disable the feature by setting JAVA_TOOL_OPTIONS=-Dturbovnc.gii=0 in the environment (from a Terminal prompt), then launching the TurboVNC Viewer with /opt/TurboVNC/bin/vncviewer.

Thanks for the info, I'll let you know how I go with the direct connection using turbovnc then accessing the novnc console in proxmox.

Copy paste works between viewers, its just that I loose keyboard functionality while connected with nomachine and from within the nomachine session I start the turbovnc session.

TurboVNC / turbovnc

Keyboard mapping issues with 2.2.80 alpha #290