RDM built-in VNC (default) sends unsupported key codes
RDM 2026.2.5.1, macOS 26.6.2. Built-in VNC (DevolutionsVnc) sends QEMU Extended Key Event with keysym=0x00000000; only keycode is set. TigerVNC 1.16.2 drops these, so pointer works and no character key registers. Modifiers and "Send Ctrl+Alt+Del" work because they use classic KeyEvent with valid keysyms. Reproduced against Xvnc on Ubuntu and WinVNC on Windows Server 2025. Removing pseudo-encoding -258 from SetEncodings restores full keyboard. Worked prior to the 2026-09-09 build; macOS unchanged since 2026-08-13.
All Comments (1)
Hello
Sorry about this.
We do enable the QEMU pseudo-encodings if the server supports it, and that was specifically to properly support ProxMox. I was not aware that there a VNC server would support the encoding but disregard the scan codes from the key message. VNC is a little bit like the Wild West in this way, when we consider feature sets and server support.
I've made a fix that we'll no longer advertise the QEMU encoding unless we know we're talking to a ProxMox host. That will be in 2026.3.1 and any subsequent 2026.2 releases (although I'm not sure if there will be any more 2026.2 releases at this time).
Once again, sorry for the inconvenience. The workaround for now is to downgrade to the a version before the problematic one you identify until the fix is released, or use a 3rd party VNC client and "external" mode in RDM.
Please let me know if you have further questions or comments
Kind regards,
Richard Markievicz