Linux 2026.3.0.5: Keypresses to RDP are submitted with wrong keyboard layout

Same here.
Fedora 44 KDE, german keyboard.
Try with switch input language to german and german-german. type "<" on german keyboard -> "," in the rdp session. / "Sihft"+"<" -> ":"

Here the aggregated AI-Help:
German Keyboard Layout (105-key ISO) Mapped to US Scancodes in RDP Sessions
Environment

• RDM Version: 2026.3.0.5 (Linux, installed via dnf / RPM)
• Previous Working Version: 2026.2.x
• Client Host: Linux (German 105-key QWERTZ physical keyboard)
• Target Host: Windows Server / Windows Desktop (Session keyboard layout set to German DEU)

Description
After updating from 2026.2.x to 2026.3.0.5, keyboard input inside active RDP sessions behaves as if keysyms are being re-mapped through a static US-ANSI scancode lookup table before transmission, rather than passing raw 105-key ISO hardware scancodes.
The extra ISO key (< / >) and several standard German keys are sent as US scancodes, which the German Windows target then re-interprets according to German layout rules, resulting in wrong characters and unreachable symbols (\, |).
Key Mapping Behavior

Physical Keystroke (DE Layout)
Expected Output
Actual Output in RDP
Probable Cause / Sent US Scancode

<
<
,
Sent as US comma key (0x33) $\rightarrow$ unshifted on DE target is ,

Shift + < (>)
>
:
Sent as US period key (0x34) $\rightarrow$ shifted on DE target is :

- (next to right Shift)
-
ß
Sent as US minus key (0x0C) $\rightarrow$ unshifted on DE target is ß

Shift + -
_
?
Sent as US shifted minus (0x0C) $\rightarrow$ shifted on DE target is ?

Shift + ß
?
_
Swapped with the minus key

Alt Gr + ß
\
#
Sent as US backslash key (0x2B) $\rightarrow$ interpreted on DE target as #

Alt Gr + <
|
#
Sent as US pipe key (0x2B) $\rightarrow$ interpreted on DE target as #

Ctrl + Alt + <
|
#
Same as Alt Gr + <

Ctrl + Alt + ß
\
\
Works as expected

Troubleshooting Steps Already Verified

1. Send input as unicode: Confirmed set to No (both globally and in session configuration).
2. Keyboard layout settings: Issue persists whether set to Default or explicitly to German (0x00000407).
3. Display Backend: Tested with both native Wayland and forced X11 via GDK_BACKEND=x11 /bin/remotedesktopmanager; behavior remains identical under both backends.
4. Target layout: Windows session confirms German (DEU) layout active.

This appears to be a regression in the FreeRDP/input handling pipeline in 2026.3.0.5 when translating Linux XKB/Evdev key events into RDP scancodes for non-US ISO layouts.

Hello,

Thank you for reaching out regarding this matter.

Based on my initial observations and analysis, this appears to be a regression. I will investigate the issue further tomorrow and follow up with our findings and the next steps.

Thank you for your patience and understanding. We apologize for the inconvenience this causes.

Best regards,

Last week I already filed a bug report and the support told me they have a Ticket open for the development Team.

So things seem to be ongoing. I hope this gets resolved soon since there are so many improvements but this is a blocker for the new version for me (since we're using the german keyboard everywhere).

Hello,

Thank you for following up.

You are correct. This topic has been linked to the current internal case regarding this issue.

I will follow up here as soon as a fix is deployed in a future version.

Thank you for your patience.

Best regards,

Same issue here with a Turkish Q layout — Arch-based (CachyOS), KDE Plasma 6.7.5 on Wayland, RDM under XWayland. After 2026.2.2.2 → 2026.3.0.5, typing , gives ö and . gives ç in the RDP session, while ç itself comes through correctly. Those are the US-layout positions of , and ., so the client seems to map the typed character to a US VK/scancode, not the physical key. Characters with no US equivalent seem to go through as Unicode.
Setting "Send input as Unicode = No" (globally and on the entry) and setting the entry keyboard layout to Turkish Q made no difference. Downgrading to 2026.2.2.2 fixes it.