search

TurboVNC / turbovnc

Main TurboVNC repository
https://TurboVNC.org
GNU General Public License v2.0
789 stars 142 forks source link

v3.1+: Keyboard layout of client not respected with container `jupyterlab/qgis/base` (noVNC v1.5.0) #423

Closed benz0li closed 1 month ago

benz0li commented 2 months ago

[...] If you feel that this is a TurboVNC issue, then please post an issue on our tracker with more information that might help me reproduce it.

Originally posted by @dcommander in https://github.com/novnc/noVNC/issues/1886#issuecomment-2284106166

Docker (or Podman) is required for reproduction.

To build the images (noVNC v1.5.0) yourself:

git clone https://github.com/b-data/jupyterlab-qgis-docker-stack.git
cd jupyterlab-qgis-docker-stack

Apply the following patch in order to use the releases from this GitHub repository:

diff --git a/base/Dockerfile b/base/Dockerfile
index d734a08..537abda 100644
--- a/base/Dockerfile
+++ b/base/Dockerfile
@@ -469,6 +469,15 @@ RUN export PIP_BREAK_SYSTEM_PACKAGES=1 \
   && rm -rf /tmp/* \
     ${HOME}/.cache

+ARG NO_VNC_VERSION=1.5.0
+
+RUN cd /usr/local/lib/python3.12/site-packages/jupyter_remote_desktop_proxy/share/web \
+  && rm -rf noVNC \
+  && git clone https://github.com/novnc/noVNC.git noVNC \
+  && cd noVNC \
+  && git checkout v${NO_VNC_VERSION} \
+  && sed -i "s/'websockify'/window.location.pathname.replace(\/[^\/]*$\/, \'\').substring(1) + 'websockify'/g" app/ui.js
+
 ## Install QGIS related stuff
 RUN apt-get update \
   ## Install QGIS-Plugin-Manager
cd base
docker build \
  --progress plain \
  --build-arg QGIS_VERSION=3.38.1 \
  --build-arg SAGA_VERSION=9.1.3 \
  --build-arg PROC_SAGA_NG_VERSION=1.0.0 \
  --build-arg PYTHON_VERSION=3.12.5 \
  --build-arg GIT_VERSION=2.46.0 \
  --build-arg TURBOVNC_VERSION=3.1 \
  --build-arg NO_VNC_VERSION=1.5.0 \
  -t jupyterlab/qgis/base \
  -f Dockerfile .

Run the image:

docker run -it --rm -p 8888:8888 jupyterlab/qgis/base start-notebook.sh --IdentityProvider.token=''

Open http://127.0.0.1:8888/lab in any browser and click QGIS Desktop.

Works as expected for TURBOVNC_VERSION=3.0.3 but does not for TURBOVNC_VERSION=3.1.

FYI @CendioOssman

benz0li commented 2 months ago

For my use case (JupyterLab QGIS docker stack currently using noVNC v1.5.0 + TurboVNC 3.1.2), https://github.com/TurboVNC/turbovnc/commit/b4fd6ae2a15f08c6052918d29511dffe37e4dae3 does not seem to play nicely with https://github.com/novnc/noVNC/commit/a0b7c0dac5359e4002e7f1d946e60e2eb9b4a54e.

Maybe you @dcommander and @CendioOssman can find out together why this is the case.

(I am currently patching noVNC v1.5.0)

benz0li commented 2 months ago

@dcommander If you think https://github.com/TurboVNC/turbovnc/commit/f683a73b4adaadf04991bc86ba2a6d07472f6452 is not a workaround but the solution, please close this issue.

ℹ️ The following work fine for my use case:

benz0li commented 2 months ago

~/.vnc/*.log for TurboVNC v3.1.2 + noVNC v1.4.0 – which works fine for my use case – contains

TurboVNC Server (Xvnc) 64-bit v3.1.2 (build 20240808)
Copyright (C) 1999-2024 The VirtualGL Project and many others (see README.md)
Visit http://www.TurboVNC.org for more information on TurboVNC

...
13/08/2024 13:47:23 [1] Enabling QEMU Extended Key Event protocol extension
...
13/08/2024 13:47:23 [1] WARNING: Disabling QEMU Extended Key Event extension because neither LED state
13/08/2024 13:47:23 [1]   extension is supported by the client.
...
dcommander commented 2 months ago

As I mentioned under the noVNC issue, f683a73b4adaadf04991bc86ba2a6d07472f6452 (post-3.1.2 commit) now allows disabling server-side key mapping in the TurboVNC Server, so you can use that as a temporary workaround to make the TurboVNC Server emulate the pre-3.1 behavior.

I will try to reproduce the issue.

benz0li commented 2 months ago

~/.vnc/*.log for TurboVNC v3.1.2 + noVNC v1.5.0 – which does not work for my use case – contains

TurboVNC Server (Xvnc) 64-bit v3.1.2 (build 20240808)
Copyright (C) 1999-2024 The VirtualGL Project and many others (see README.md)
Visit http://www.TurboVNC.org for more information on TurboVNC

...
13/08/2024 13:13:02 [1] Enabling QEMU Extended Key Event protocol extension
13/08/2024 13:13:02 [1] Enabling QEMU LED State protocol extension
...
ich777 commented 1 month ago

Same here with TurboVNC 3.1.2 and noVNC 1.5.0

Downgraded to noVNC 1.4.0 for now and awaiting the fix or better speaking the release from TurboVNC 3.1.3 with the new command line option that @dcommander linked.

dcommander commented 1 month ago

I tested the container, and it works properly within the expectations of TurboVNC 3.1. As you observed, the client-side keyboard layout is not respected, but that's a feature, not a bug. The unmodified RFB protocol sends X11 keysyms from client to server. Because keysyms are post-keyboard-mapping, that makes it impossible to exactly emulate certain keyboard features, because there is a lot of variation in how client operating systems map raw keyboard scancodes to keyboard events. This was particularly found to be an issue with dead keys on international keyboards. That's why server-side key mapping, using the QEMU/VMware RFB keyboard extensions, was implemented in TurboVNC. Those extensions allow the VNC viewer to send raw keyboard scancodes to the server, thus eliminating the client-side keyboard mapping differences. To put it another way, the goal of TurboVNC is to emulate a local Linux desktop, and on a local Linux desktop, you adjust the keymap using the tools provided by the Linux distribution/window manager. Without server-side key mapping, there are several stages of keyboard translation: (1) from raw scancodes to O/S-specific key codes/keysyms on the client, which is subject to the client-side keymap and O/S idiosyncrasies, (2) from O/S-specific key codes/keysyms to X11 keysyms in the VNC viewer, which is an imperfect science at best, and (3) from X11 keysyms back to raw scancodes in the VNC server. In practice, none of those stages is fully reversible, so you can't exactly emulate the keyboard behavior of a Linux desktop unless you use server-side key mapping. Without server-side key mapping, the aforementioned tools not only don't work, but they can actually change the behavior of Stage 3. (Thus, with client-side key mapping, the ugly reality is that not all of the key mapping can be done on the client.)

If the server-side key mapping feature is not working as documented, or if it is creating an undue burden upon users, then I am certainly willing to address those issues. However, if the principal complaint is that the feature exists, then the only thing I can do is what I have already done: provide a way to disable it (https://github.com/TurboVNC/turbovnc/commit/f683a73b4adaadf04991bc86ba2a6d07472f6452). IMHO, noVNC should also provide a way to disable it, as the TurboVNC Viewer does, but since they seem unwilling to do that, I don't know what else I can do.

benz0li commented 1 month ago

I am currently patching noVNC v1.5.0

https://github.com/b-data/jupyter-remote-desktop-proxy/blob/554f60bdcd1a779a01df5f81684b2e0df2254855/jupyter_remote_desktop_proxy/share/web/noVNC-1.5.0.patch

i.e.

👉 The patch also includes custom JS and CSS modifications for vnc.html.

dcommander commented 1 month ago

@benz0li The patch appears to only disable the QEMU LED State pseudo-encoding, which means that the QEMU Extended Key Event pseudo-encoding will still be advertised to the server. The QEMU Extended Key Event extension is what implements server-side key mapping. QEMU LED State is a supplement to that extension that enables remote lock key synchronization. If you want to fully disable the feature from the client side, you need to disable both extensions.

It would be helpful to have a better understanding of why you can't use server-side key mapping, i.e. what issues you observed with it that make you want to completely cancel it. From my point of view, there is no bug here. There is only a behavior change that is well justified. If you believe that there is a bug, then I need to understand why. If there is an esoteric use case that could be better supported, then I am happy to discuss how best to support it.

ich777 commented 1 month ago

It would be helpful to have a better understanding of why you can't use server-side key mapping

For me it is because I'm using TurboVNC in Docker containers and not all key maps from the servers are set correctly and it could be a real pain to tell users what they have to do to actually change that, hope such a short answer makes sense.

benz0li commented 1 month ago

It would be helpful to have a better understanding of why you can't use server-side key mapping

For me it is because I'm using TurboVNC in Docker containers and not all key maps from the servers are set correctly and it could be a real pain to tell users what they have to do to actually change that, hope such a short answer makes sense.

@dcommander Same for me.