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.

Hello,

Thank you for being so patient!

If possible, could you update your RDM Linux to the latest version (2026.3.1.1) and see if the problem persists? This version should resolve your issue.

Latest Version: Download RDM

If the problem persists after the update, please let us know so we can inform our development team.

Best regards,

Hello,

I just upgraded RDM and can confirm that the Keyboard Layout is now working as expected.

But another thing I found and is maybe related:

I cannot pass through Shortcuts. For instance: If I have press ctrl+b I get asked the authentication for a connection instead of passing it through to the session. This is annoying when working with an open putty+tmux session in an RDP Connection. I also didn't find anything related to the shortcuts in the settings.

Shoud I file a new bug report for this?

thank you for resolving this issue. Now at least I am able to use the new version!

kind regards,

@cf2 ,

Yes please, open a separate thread for the new issue / bug.

It would be better for the community and the Devolutions teams to follow thread by thread (topic by topic).

Thank you

Best regards,