UPDATE: The root cause has now been definitively identified, and it is
NOT what this report originally described. Please disregard the
"regression after Ubuntu security update" framing - that was a
misdiagnosis. This is not an Ubuntu packaging issue and not a Remmina
bug.

ROOT CAUSE: xorgxrdp

The problem occurs only when an RDP client runs inside an xrdp session
backed by xorgxrdp. Switching the xrdp session backend from xorgxrdp to
Xvnc (TigerVNC) resolves the issue completely - same client, same
versions, same target host, correct keyboard behaviour for both y/z and
arrow keys.

TEST MATRIX

Broken (xorgxrdp backend):
- Remmina 1.4.43 on Ubuntu 26.04 (xrdp 0.10.1 / xorgxrdp 0.10.2) -> y/z 
swapped, Down arrow produces Enter
- Remmina 1.4.41 on Fedora 44 (xrdp 0.10.x / xorgxrdp 0.10.5) -> identical 
symptoms
- Remmina 1.4.40 (downgrade on Ubuntu) -> identical symptoms
- Remmina Flatpak build (org.remmina.Remmina from Flathub) -> identical symptoms
- GNOME Connections -> identical symptoms
- KRDC -> identical symptoms

Working:
- Remmina 1.4.41 on a Fedora 44 workstation with native Xorg (physical 
keyboard) -> correct
- Remmina in an xrdp session using the Xvnc backend instead of xorgxrdp -> 
correct
- Standalone xfreerdp3 executed from a terminal inside the same broken xorgxrdp 
session -> correct (both Ubuntu and Fedora)

ANALYSIS

Three independent GUI clients (Remmina, GNOME Connections, KRDC) that
embed libfreerdp all fail identically, while the standalone xfreerdp
client succeeds in the very same X session. This points to how
libfreerdp derives its scancode mapping when embedded, in combination
with xorgxrdp's virtual keyboard device.

One concrete difference: inside an xorgxrdp session, `setxkbmap -query`
reports `rules: base` rather than the usual `rules: evdev`. Forcing
evdev rules with `setxkbmap -rules evdev -model pc105 -layout de`
partially fixes the problem - y/z become correct - but arrow keys remain
broken, suggesting the extended scancode path is affected separately.

The xorgxrdp session itself receives the correct layout: its log shows
"rdpLoadLayout: keylayout 0x00000407" (German), and xfreerdp3's debug
output in that same session correctly derives extended scancodes from
XKB (UP: keycode 0x98 -> rdp scancode 0x148, DOWN: keycode 0x104 -> rdp
scancode 0x150). The information is present and correct; the embedded
path just doesn't arrive at the same result.

RULED OUT

- Windows server side: no IgnoreRemoteKeyboardLayout registry value, no 
relevant GPO (verified via gpresult), no keyboard layout redirection policy. 
Switching the input language inside the running session does not help, 
confirming the mapping is fixed at connection negotiation time.
- xrdp server side: xrdp_keyboard.ini regenerated via xrdp-genkeymap with the 
correct layout active; XFCE layout set persistently via xfconf (de/pc105). No 
effect.
- Remmina's "Use client keyboard mapping" option: enabling it fixes y/z but 
breaks arrow keys entirely; disabling it restores arrows but reintroduces the 
y/z swap. Neither state is correct.

SUGGESTED ACTION

This report is filed against the wrong package. It should be reassigned
to xorgxrdp, or closed as Invalid and refiled there - or taken upstream
to https://github.com/neutrinolabs/xorgxrdp. I'm happy to provide
further logs or run tests if that helps.

WORKAROUND

Switch the xrdp session backend from xorgxrdp to Xvnc (move the [Xvnc]
block above [Xorg] in xrdp.ini). Alternatively, use standalone xfreerdp
instead of a GUI client.

** Changed in: remmina (Ubuntu)
       Status: New => Invalid

** Package changed: remmina (Ubuntu) => xorgxrdp (Ubuntu)

-- 
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/xorgxrdp/+bug/2161875/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to