AltGr sending Control_L + Alt_L from client, on a Microsoft Azure VM

[MBD62]

Describe the bug
It looks to me like the TigerVNC viewer sends something different when pressing AltGr than the RealVNC viewer does. (German keyboard)

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
Pressing Alt Gr would be recognized as "ISO_Level3_Shift"

Screenshots

Client (please complete the following information):

• OS: Windows 11 Enterprise multi-session)
• VNC client: TigerVNC
• VNC client version: 1.14.0
• Client downloaded from: sourceforge.net

Server (please complete the following information):

• OS: AlmaLinux 9.1
• VNC server: TigerVNC
• VNC server version:1.13.1
• Server downloaded from: AlmaLinux repository
• Server was started using: Started at boot, after having executed systemctl enable vncserver@:77.service.

Additional context
As described in #1818 , typing in general started working when setting the keyboard to "German" instead of "Auto" in the Azure settings. However, anything involving Alt Gr still types nothing. A RealVNC viewer and a TightVNC viewer both work fine in the same setup.

Output of xev in the Linux-session and the Viewer log-file in Windows both agree with the fact that pressing Alt Gr sends Control_L + Alt_L (keycode 37 (keycode 37 (keysym 0xffe3, Control_L) and keycode 64 (keysym 0xffe9, Alt_L). Pressing the left Alt-key sends the same, just without the Control_L: keycode 64 (keysym 0xffe9, Alt_L) The keycode/keysym combos are the same in the Windows viewer logfile as are shown by xev. (suggesting that, for some reason, the viewer is sending the wrong thing?)

A current workaround is to use xmodmap -e "keycode 96 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift" , for example. On my keyboard I then hold down to type the characters requiring Alt Gr. When others use the same VM, who have perhaps Italian or French keyboards, it would have to be figured out what they may have for useable keys to apply xmodmap on so that is suboptimal.
I tried setting the server to use the rawkeyboard option but that does not change the behavior.

Another workaround, of course, could be to use one of the other viewers, but the combo Tiger server and Tiger viewer has its advantages.... Curiously enough, #1715 and #1751 both seem to describe the opposite problem, TigerVNC viewer working fine but other viewers failing.

Any ideas?

thx in advance + best regards / Mats

[MBD62]

I apparently did something wrong trying to insert links to other issues, maybe this works: #1715 , #1751 , #1818

[CendioOssman]

AltGr is unfortunately very buggy on Windows. So my guess would be that you are not getting a proper emulation of the Windows behaviour in that Windows VM.

How are you accessing the Windows VM? Microsoft's RDP client?

A client debug log would be helpful:

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

[MBD62]

Hi CendioOssman,
access is through a Web-browser but yes, RDP apparently does it in the background.
vncviewer.log

The attached logfile was with a session with the following keystrokes:
<RETURN>
<AltGr> + <\> (produces nothing)
<RETURN>
<F12> + <\> (produced "" in the terminal, which responded with "?"
<RETURN>
<Alt>
<RETURN>
(I hope I got the order right....)
Thx

[MBD62]

Oh, I violated some syntax, so it did not come out right: Between each keystroke I hit the return-key, the keys I hit were AltGr + backslash, got nothing, then F12 +backslash, got backslash and the terminal was confused. Last I hit the left Alt-key.

[MBD62]

AltGr is unfortunately very buggy on Windows. So my guess would be that you are not getting a proper emulation of the Windows behaviour in that Windows VM.

How are you accessing the Windows VM? Microsoft's RDP client?

A client debug log would be helpful:

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

The TightVNC- and RealVNC-viewers are working OK. Does this mean that they internally translate things differently from how the TigerVNC-viewer does it or do, when they are in use, other keycodes/keysyms come out?

Back when collecting a viewer-log for #1818 the RealVNC viewer log showed no keystrokes, as far as I could tell. I will make a log with TightVNC and see if that shows something on keytrokes.

[MBD62]

I failed to create a logfile with the TightVNC viewer. The executable has an option -logpath but I wasn't able to get it tp produce a logfile. I created a new logfile from the RealVNC-viewer but like in my previous attempt, I'm not seeng any keytrokes at all in that log. Attaching it here.
RealVNCvncviewer.log

[MBD62]

The stuff in #1847 and subsequently #1852 looks interesting. If going back to the keyboard-setting used at the time of my submitting #1818 the fix for VK_PACKET may make it work. (with the German keyboard set in Azure I don't see VK_PACKET but I do with the keyboard set to Auto)

Unfortunately I don't know how to build from source-code so I'd have to wait for this to get into an update.

[MBD62]

Looking at the RealVNCvncviewer.log, two sets of entries like this may explain why that log contains no keystroke info at all:
<15> 2024-10-23T09:01:41.817Z WinVM-EU-0 vncviewer[9692]: Feature: Enable RecordInputs (failed)
<15> 2024-10-23T09:01:41.817Z WinVM-EU-0 vncviewer[9692]: Feature: Enable PlayInputs (failed)

[CendioOssman]

Hi CendioOssman,
access is through a Web-browser but yes, RDP apparently does it in the background.
vncviewer.log

Thank you. Unfortunately, the log does show a buggy behaviour from the RDP client you are using. It is not sending AltGr the same way that a "real" Windows machine does.

To fix this, we would need to figure out some way to detect this broken behaviour. Nothing obvious in the log on how to do that, though. And it might not be possible.

Someone with access to such a system would need to analyse the events more deeply and see if there are any hints.

Have you reported this issue to Microsoft/Azure?

The TightVNC- and RealVNC-viewers are working OK. Does this mean that they internally translate things differently from how the TigerVNC-viewer does it or do, when they are in use, other keycodes/keysyms come out?

They likely use the crude method we also used to have. Unfortunately, that method breaks other use cases. Like pressing Ctrl and AltGr at the same time.

I failed to create a logfile with the TightVNC viewer. The executable has an option -logpath but I wasn't able to get it tp produce a logfile. I created a new logfile from the RealVNC-viewer but like in my previous attempt, I'm not seeng any keytrokes at all in that log. Attaching it here.
RealVNCvncviewer.log

Was this with debug settings, as documented here:

https://help.realvnc.com/hc/en-us/articles/360002321517-How-do-I-generate-debug-logs-in-RealVNC-Connect#realvnc-viewer-windows-macos-linux--0-3

[MBD62]

Was this with debug settings, as documented here:

https://help.realvnc.com/hc/en-us/articles/360002321517-How-do-I-generate-debug-logs-in-RealVNC-Connect#realvnc-viewer-windows-macos-linux--0-3

No, it was with the settings described in the original link above, *:file:100.
vncviewer.log
The new log was with "Debug", still has these lines as the other one, with 'failed' where it looks like keystroke recording is not successful.

Seeing some potential in a possible fix to #1847 , I will close this issue and wait for that fix to end up in a new executable. (and just use RealVNC-viewer for now) In parallel I'll try and find some other key than the F12 to use with xmodmap to generate ISO_Level3_Shift.

I have not reported to uSoft Azure, thinking they, like IT-support, will suggest to use another viewer instead.
Thanks for looking at this.

[svenssonaxel]

Unfortunately I don't know how to build from source-code so I'd have to wait for this to get into an update.

Author of #1852 here. Figuring out how to build indeed took the majority of the time. I contributed an easier way to build in #1854. If you want to try that, you'd have to merge both PRs locally.

[svenssonaxel]

To fix this, we would need to figure out some way to detect this broken behaviour. Nothing obvious in the log on how to do that, though. And it might not be possible.

@MBD62 If you can download keyboa and run listenkey -dlc on both machines (where AltGr works and where it doesn't), then maybe we can figure out such a way. This program will print lots of keyboard layout information, then consume and print 30 key events. So try something similar, AltGr+\ or something and we'll see how it compares. Note that you must press and release about 15 keys before you'll be able to use your keyboard in another applicaton.

[MBD62]

To fix this, we would need to figure out some way to detect this broken behaviour. Nothing obvious in the log on how to do that, though. And it might not be possible.

@MBD62 If you can download keyboa and run listenkey -dlc on both machines (where AltGr works and where it doesn't), then maybe we can figure out such a way. This program will print lots of keyboard layout information, then consume and print 30 key events. So try something similar, AltGr+\ or something and we'll see how it compares. Note that you must press and release about 15 keys before you'll be able to use your keyboard in another applicaton.

I have attached four textfiles collected. Two using the RealVNC-viewer and two using the TigerVNC-viewer. One pair with The Azure web-interface keyboard-setting to German and the second pair with that setting to Auto.
RealVNC-viewer is OK in both settings.
TigerVNC-viewer does all but AltGR-keys with the German setting and pretty much nothing at all in the Auto setting.
RealVNCviewer__Works.txt
RealVNCviewer__WorksAutoKB.txt
TigerVNCviewer__notOK.txt
TigerVNCviewer__notOKautoKB.txt