UPDATE: Further testing has significantly narrowed down the root cause. The issue is NOT distribution-specific, NOT version-specific, and NOT caused by the Ubuntu security update as originally suspected. Please disregard the "regression after security update" framing in the original report.
NEW FINDINGS The problem occurs exclusively when Remmina runs *inside* an xrdp/xorgxrdp X11 session (i.e. a "jump host" scenario), regardless of distribution or package version. Test matrix: 1. Remmina 1.4.41 on a Fedora 44 workstation (native Xorg, physical keyboard) -> connects to the same Windows RDP host -> keyboard works correctly (y/z correct, arrow keys correct). 2. Remmina 1.4.41 on a freshly installed Fedora 44 server running xrdp 0.10.x + xorgxrdp 0.10.5, connected to via RDP, then connecting onward to the same Windows RDP host -> BROKEN (y/z swapped, Down arrow produces Enter/newline). 3. Remmina 1.4.43 on Ubuntu 26.04 with xrdp 0.10.1 + xorgxrdp 0.10.2, same nested scenario -> BROKEN, identical symptoms. 4. Downgrading Remmina to 1.4.40+dfsg-2ubuntu1 on Ubuntu -> still BROKEN. 5. Flatpak build of Remmina (org.remmina.Remmina from Flathub) in the nested scenario -> still BROKEN. 6. Standalone xfreerdp3 (same FreeRDP version, same target host, same credentials), executed from a terminal *inside the very same xrdp session* where Remmina fails -> WORKS CORRECTLY. Both y/z and arrow keys behave as expected. CONCLUSION Since xfreerdp3 and Remmina share the same libfreerdp and talk to the same X server in test 6, the difference must lie in how Remmina's RDP plugin derives and reports the keyboard layout / scancode mapping to the FreeRDP core. This derivation appears to work correctly against a "real" Xorg with a physical input device, but produces an incorrect mapping against xorgxrdp's virtual keyboard device. Notably, the xorgxrdp session itself receives the correct layout - the xorgxrdp session log shows "rdpLoadLayout: keylayout 0x00000407" (German), and `setxkbmap -query` inside the session correctly reports layout=de, model=pc105. xfreerdp3's debug output in that same session confirms it correctly derives extended scancodes from XKB (UP: keycode 0x98 -> rdp scancode 0x148, DOWN: keycode 0x104 -> rdp scancode 0x150). So the information is available and correct - Remmina just doesn't use it the same way. RULED OUT - Windows server side: no IgnoreRemoteKeyboardLayout registry value set (default 0), no relevant GPO applied (verified via gpresult), no "Do not allow keyboard layout redirection" policy enabled. Manually switching the input language inside the running RDP session does not fix it, confirming the mapping is fixed at connection negotiation time. - xrdp server side: xrdp_keyboard.ini regenerated with xrdp-genkeymap while the correct German layout was active; XFCE keyboard layout set persistently via xfconf (de/pc105) - no effect on Remmina's behavior. - Remmina's "Use client keyboard mapping" option: enabling it fixes y/z but breaks arrow keys entirely; disabling it restores arrow keys but reintroduces the y/z swap. Neither state is correct. This likely belongs upstream (see https://gitlab.com/Remmina/Remmina/-/issues/2636, "Wrong keyboard mapping using RDP, but standalone FreeRDP works", which appears to describe the same underlying mechanism) rather than being an Ubuntu packaging issue. Reassigning or forwarding upstream may be appropriate. WORKAROUND IN PRODUCTION Using a Remmina "Exec" protocol profile that wraps xfreerdp3 directly avoids the issue entirely and is transparent to end users. ** Bug watch added: gitlab.com/Remmina/Remmina/-/issues #2636 https://gitlab.com/Remmina/Remmina/-/issues/2636 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2161875 Title: remmina-plugin-rdp: arrow keys and y/z keys wrongly mapped when connecting to Windows RDP server (regression after security update, standalone xfreerdp3 unaffected) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/2161875/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
