Public bug reported:
[Impact]
On Ubuntu 26.04, a Windows client with a Japanese 109 keyboard (RDP keyboard
type 7) cannot type the yen/backslash key (the key left of Backspace,
scancode 0x7D) over RDP to a FreeRDP-based server such as gnome-remote-desktop
Remote Login. Pressing the key produces nothing, and Shift+key (pipe, |) also
produces nothing. Since \ and | are essential for file paths, shells and
programming, a Japanese keyboard is significantly impaired over RDP.
The cause is libwinpr's Japanese type-7 scancode-to-virtual-key table.
In winpr/include/winpr/input.h, scancode 0x7D is defined as:
#define KBD7_T7D VK_NONE
so GetVirtualKeyCodeFromVirtualScanCode() returns VK_NONE for the key and the
event is dropped. On a Japanese keyboard, scancode 0x7D is the yen sign key
and must map to VK_OEM_8 (cf. the Windows KBDJPN layout: scancode 7d ->
VK_OEM_8, producing YEN SIGN / BROKEN BAR).
The table is used only for keyboard type 7 (WINPR_KBD_TYPE_JAPANESE); other
keyboard types are unaffected.
Note: gnome-remote-desktop in 26.04 (50.0) already contains the companion
upstream fix that passes the client's real keyboard type to
GetVirtualKeyCodeFromVirtualScanCode() instead of hardcoding IBM enhanced
(https://gitlab.gnome.org/GNOME/gnome-remote-desktop/-/commit/c9b138c9),
so the type-7 table is actually consulted on 26.04 and this FreeRDP table
gap is the only remaining piece.
Upstream FreeRDP fixed the table in commit
325d47f7a3c0f21baf48302569e65bb5ff5fe6d9 ("[winpr,input] complete japanese
keyboard mapping", PR #12836), first released in FreeRDP 3.27.0 (2026-06-15).
Ubuntu 26.04 ships 3.24.2, which predates it. Besides 0x7D, the commit fills
other missing Japanese-specific entries (e.g. scancode 0x79 -> VK_HKTG) and
adds a unit test verifying scancode<->vkcode round-trips for all keyboard
types.
[Test Plan]
Table-level check (no RDP session needed) —
GetVirtualKeyCodeFromVirtualScanCode() is exported by libwinpr:
cat > kbd7t-repro.c <<'EOF'
#include <stdio.h>
#include <winpr/input.h>
int main(void) {
DWORD vk = GetVirtualKeyCodeFromVirtualScanCode(0x7D,
WINPR_KBD_TYPE_JAPANESE);
printf("scancode 0x7D (yen key) -> VK 0x%02X, expect 0xDF (VK_OEM_8)\n",
vk);
return vk == VK_OEM_8 ? 0 : 1;
}
EOF
sudo apt-get install -y build-essential pkg-config libwinpr3-dev
gcc kbd7t-repro.c $(pkg-config --cflags --libs winpr3) -o kbd7t-repro
./kbd7t-repro; echo "exit=$?"
Before the fix (3.24.2+dfsg-1ubuntu1.1):
scancode 0x7D (yen key) -> VK 0x00, expect 0xDF (VK_OEM_8)
exit=1
After the fix:
scancode 0x7D (yen key) -> VK 0xDF, expect 0xDF (VK_OEM_8)
exit=0
End-to-end check: from Windows 11 with a Japanese 109 keyboard, connect with
mstsc.exe to Ubuntu 26.04 gnome-remote-desktop (Remote Login). In a terminal,
press the yen key -> should input \ (or ¥ depending on the input source);
Shift+yen key -> |. Before the fix, both produce nothing.
I have verified on Ubuntu 26.04 that rebuilding the freerdp3 3.24.2 source
package with the KBD7_T7D VK_NONE -> VK_OEM_8 change restores the key
end-to-end through gnome-remote-desktop Remote Login.
[Where problems could occur]
The change is confined to the Japanese type-7 tables (KBD7*) in libwinpr's
input mapping, consulted only when the RDP client reports keyboard type 7
(WINPR_KBD_TYPE_JAPANESE). IBM enhanced (type 4), Korean (type 8) and the
other types use separate tables and cannot regress.
A regression would show up as a mistyped key for Japanese type-7 clients
only, if a table entry were mistranscribed. The upstream commit includes a
unit test (winpr/libwinpr/input/test/TestScancode.c) that verifies the
scancode<->vkcode round-trip for all 8 keyboard types.
Two packaging notes:
- The upstream commit also introduces a new exported helper,
GetVirtualScanCodesFromVirtualKeyCode() (additive; no ABI break for
existing symbols). If preferred, the backport can be trimmed to the table
fixes only.
- The patch touches the same area as
d/p/lp2154803-fix-korean-keyboard-type8-mapping.patch
(3.24.2+dfsg-1ubuntu1.2, currently in the resolute queue), so it should be
stacked after that patch in debian/patches/series.
[Other Info]
Fixed upstream in FreeRDP 3.27.0.
Upstream PR: https://github.com/FreeRDP/FreeRDP/pull/12836
Upstream commit:
https://github.com/FreeRDP/FreeRDP/commit/325d47f7a3c0f21baf48302569e65bb5ff5fe6d9
Key hunk (winpr/include/winpr/input.h):
-#define KBD7_T7D VK_NONE
+#define KBD7_T7D VK_OEM_8
The current devel series already ships 3.28.0+dfsg-1 (>= 3.27.0), so the
devel task is already fixed; this request is for resolute (26.04).
Related bugs:
- LP: #2113452 tracks the same user-visible symptom on 24.04 against
gnome-remote-desktop. On noble, g-r-d 46.x additionally lacks the
companion g-r-d fix (c9b138c9), so both changes would be needed there.
On 26.04 only this FreeRDP change is missing.
- LP: #2154803 is the direct precedent: the analogous Korean (type 8)
table fix was backported into 3.24.2+dfsg-1ubuntu1.2 the same way
(upstream commit 35d61e5, in 3.25.0).
Environment:
- Ubuntu release: 26.04 resolute
- Package: libfreerdp3-3 3.24.2+dfsg-1ubuntu1.1
- Remote desktop server: gnome-remote-desktop 50.0-0ubuntu2, Remote Login RDP
- Client OS: Windows 11 (Japanese)
- Client software: mstsc.exe
- Keyboard: Japanese 109 (RDP keyboard type 7)
Expected result:
Pressing the yen key types \ / ¥; Shift+yen types |.
Actual result:
Both produce no input at all.
Request:
Please backport upstream commit 325d47f (FreeRDP 3.27.0, PR #12836) to the
freerdp3 package in resolute, following the same approach as LP: #2154803.
** Affects: freerdp3 (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2161108
Title:
Japanese keyboard type 7: yen/backslash key (scancode 0x7D) produces
no input over RDP in GNOME Remote Desktop, fixed upstream in FreeRDP
3.27.0
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/freerdp3/+bug/2161108/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
