TigerVNC-viewer on Azure Windows-VM doesn't send alphanumerics to the TigerVNC-server

[MBD62]

Describe the bug
Is this an issue with TigerVNC, with Azure or the combination, I can't tell for sure but it looks like the combination. The currently applied workaround is to use the RealVNC-viewer instead, but the preference would be to use the TigerVNC-viewer due to its ease of display re-sizing.

When using the TigerVNC-viewer versions 1.12, 1.13 1 and 1.14, a VNC-session is unable to recognize typing of alphanumerics. Known <ctrl> +<someKey> combinations and <return> are recognized but not any "straight characters". Mouse-clicks and movements are also recognized, as are also the arrow-keys and copying/pasting text. Only typing fails. The server is TigerVNC version 1.12 on an AlmaLinux 9.1 VM in Azure. Running a viewer inside the Linux-VM is fine, as well as running a RealVNC-vewer from the Windows-VM, which seems to suggest that on the server-side things are OK. The Windows Firewall on the Windows-VM has been turned off, to no avail. (besides, some keystrokes do work, so it looks more like a keyboard-mapping issue than something being blocked from outside) This is a gnome X session, not Wayland. Btw, typing in the password in the dialog-box is, of course, not an issue. This suggests there is some subtlety with X11 keyboard-mapping. (and that mapping is presumably not yet in place when typing the password?)

Running xev in a terminal, to display keyboard-events, shows nothing when typing the character "c" but does show a response (ie something being sent from the viewer to the server) when typing <ctrl>+c.

Numerous web-searches have been attempted, not only by myself. This page, from about 20 years ago, describes identical behavior:
https://vnc-list.realvnc.narkive.com/FnbGlwJv/strange-vnc-keyboard-problem-only-alpha-keys-not-working. In that example, it was the same viewer that worked fine on some hardware but not on a specific computer.

To Reproduce
Steps to reproduce the behavior:
To reproduce this, a setup with an Azure Windows-VM used for accessing an Azure Linux-VM would be necessary. If trials need to be made, I'd of course be happy to assist but can't grant access to our VMs. The hope is that someone who understands the code, particularly around keyboard-mapping, can figure out what may be going wrong.

Expected behavior
Typing of any characters would be recognized.

Screenshots

Client (please complete the following information):

• OS: Windows 11 Enterprise multi-session)
• VNC client:TigerVNC,
• VNC client version: versions 1.12.0, 1.13.1 and 1.14.0 have been tried. (vncviewer64-1.13.1.exe, for example)
• Client downloaded from: github

Server (please complete the following information):

• OS: AlmaLinux 9.1
• VNC server: TigerVNC
• VNC server version: 1.12
• Server downloaded from: Part of the AL 9.1 distribution
• Server was started using: Started at boot, after having executed systemctl enable vncserver@:77.service. During trials the server-session has been stopped and restarted numerous times. (also with systemctl)

Additional context
We're using TigerVNC viewer in hundreds of other setups from Windows to Linux without any issues, in the Azure-setup the RealVNC-viewer works but not TigerVNC. The issues is only present in the Azure-environment but does not affect the RealVNC-viewer.

[CendioOssman]

Since it is an Azure VM, I assume you are using RDP to reach it? Sounds like an issue with Microsoft's RDP server where it is not giving realistic keyboard events.

I would suggest getting a debug log and seeing what that says:

https://github.com/TigerVNC/tigervnc/wiki/Debug-Logs#client-1

[MBD62]

Thanks CendioOssman:-) We access the Windows-VM with a browser, from there we start the viewer to the Linux-VM.
The logfile contains a lot of this:

Thu Aug 22 12:46:00 2024
 Viewport:    No scan code for virtual key 0xe7
 Viewport:    Unexpected release of key code 0
 Viewport:    No scan code for virtual key 0xe7
 Viewport:    Unexpected release of key code 0

0xe7 is described like this by learn.microsoft.com:

VK_PACKET 0xE7 Used to pass Unicode characters as if they were keystrokes. The VK_PACKET key is the low word of a 32-bit Virtual Key value used for non-keyboard input methods. For more information, see Remark in KEYBDINPUT, SendInput, WM_KEYDOWN, and WM_KEYUP

I can't make much of that, but it seems to confirm that what's being sent is not a proper keystroke, for all the keys that do not work.
There is the mention of "non-keyboard input method". My next step will be to start the RealVNC-viewer with a log-file and see what that says. thx + best regards / Mats

[MBD62]

TIGERvncviewer.log
REALvncviewer.log
Browsing through the logfiles from the two different viewer-programs does not tell me very much. The only thing I can see in the REALvncviewer.log that may remotely have anything to do with keyboard-input is a line like this:
<15> 2024-08-22T13:27:58.605Z TrainingVM-0 vncviewer[1208]: Child: 11232: LowLevelKey: hook success but I may well be mistaken.

I don't see that file recording any keystrokes, maybe that's because the keystrokes are successful with that viewer.

The TigerVNC-viewer does accept my typing the password so the problem does not seem to start until the Linux-session is started, but the RealVNC-viewer connects to the same Linux-session. Any further ideas for troubleshooting would be most welcome. With the logfile data, I may have some further things to search on the net. Will also check settings with respect to Unicode, as that was mentioned in uSoft's help.
Thanks and regards / Mats

[MBD62]

Another observation from just now: A colleague was experimenting with the TightVNC-viewer: While not in full-screen mode, that viewer can happily type and behaves just like RealVNC. Switched to full-screen mode though, it behaves much like the TigerVNC-viewer, with the exception that it has been seen, on one occasion, produce the character "r" for any typed key on the keyboard. (other than that, same behavior as TigerVNC-viewer)

[MBD62]

Closing this, the solution was a keyboard layout-setting in the Azure web access client (https://client.wvd.microsoft.com/arm/webclient/index.html) Auto-selection does not work for the TigerVNC-viewer, it must be set to a specific keyboard layout. What I had missed initially, was that one must exit out of the web-session and back in again, for a change in settings to take effect. The three different viewers had different reactions to the layout-setting, pointing stronger towards something in Azure. Thanks for the help.