RDP: AltGr (Level3) characters garbled/wrong when the X11 keycode is non-standard (FreeRDP 3.x Unicode fallback)

Published 5 days ago

Product: Remote Desktop Manager (Linux), RDP connections via bundled
FreeRDP. Note: an earlier forum reply (Simon Duguay Létourneau,
https://forum.devolutions.net/topics/9648/wrong-keyboard-layout) stated
RDM bundles FreeRDP 3.11.0 - we've since confirmed the actual version
shipped is 3.16.0, so that reply may be outdated.

Setup: RDM runs inside a browser-based Linux desktop (KasmVNC/KDE Plasma),
German ("de") keyboard layout configured both client- and server-side,
RDP connection's Keyboard Layout explicitly set to German (0x00000407).

### Symptom
- With "Send as Unicode" enabled: pressing AltGr+ß (backslash on a German
layout) inserts a garbage/incorrect character immediately before the
backslash.
- With "Send as Unicode" disabled: pressing AltGr alone is interpreted as
"@" instead of being recognized as a modifier.
- The RDP connection's Advanced tab no longer has a "Disable sandboxing"
option (present in RDM ~2 years ago per the forum thread above), so that
earlier troubleshooting step is no longer available to test.

### Root cause we were able to trace
Our browser-based desktop's VNC layer (KasmVNC) delivers the physical
AltGr key as X11 keycode 92 (a dynamically-allocated "spare" keycode)
instead of keycode 108 (the standard position for AltGr on a German XKB
layout) - confirmed via xev. We could not get KasmVNC to deliver the
correct/expected keycode without breaking AltGr composition entirely
(a separate, unresolved upstream VNC-side limitation we're pursuing with
the KasmVNC project directly).

Given that, it looks like FreeRDP's internal X11-keycode-to-VK table
doesn't recognize keycode 92 as any known key, resulting in VK_NONE, and
falls back to transmitting the composed character via Unicode input
instead of a proper AltGr-modified keypress - which is what produces both
symptoms above.

### Ask
Since the incoming X11 keycode from the display server can genuinely
vary (not every VNC/X setup delivers AltGr on the "textbook" keycode),
could the AltGr/Level3 handling be made more robust to non-standard
keycodes - e.g. by trusting the keysym (ISO_Level3_Shift) directly when
the keycode lookup fails, rather than only falling back to a raw Unicode
character transmission?

All Comments (1)

Carl Marien

Published 4 days ago

Hello,

Thank you for the very detailed report, including the root-cause trace back to the non-standard X11 keycode (92) and the FreeRDP fallback behavior. This is helpful.

We checked our internal tracking and were not able to find an existing bug report matching this exact scenario (AltGr/Level3 mishandling when the incoming X11 keycode falls outside FreeRDP's expected table). This appears to be a new finding rather than a known, already-tracked issue.

We will attempt to reproduce the behavior internally, using a similar setup (German keyboard layout, non-standard AltGr keycode delivery) to confirm the root cause on our side. We will keep you informed as we make progress on this.

Best regards,

Carl Marien