** Description changed: [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 + #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; + 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) + scancode 0x7D (yen key) -> VK 0xFF, 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. + 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. + 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. + 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). + 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.
-- 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
