What happened?
Description
When adding RDP_FLAGS="/kbd:unicode" to winapps.conf (used to get consistent keyboard-layout-switching shortcuts across different host OSes, since without it the shortcut differs per OS), the Delete key stops performing its function inside seamless WinApps applications (tested in MS Word). Instead of deleting the character to the right of the cursor, an invalid/placeholder "tofu" square glyph is inserted into the document.
This flag is not set by default — the issue only appears once the user manually enables /kbd:unicode. In my case, I enabled it specifically because the default keyboard-layout-switching shortcut (Ctrl+Shift) was not working reliably/consistently across different host OSes, and /kbd:unicode was the only combination that fixed layout switching — at the cost of breaking the Delete key as described below.
Expected behavior
Pressing Delete should delete the character to the right of the cursor, exactly as it does without /kbd:unicode enabled.
Root cause (confirmed via Windows low-level keyboard hook)
Without /kbd:unicode, pressing Delete produces a normal Windows key event:
VK=0x2E (VK_DELETE) SC=0x53 Flags=0x1 (extended)
With /kbd:unicode enabled, in seamless/RemoteApp mode, pressing Delete instead produces:
VK=0xE7 (VK_PACKET) SC=0x7F Flags=0x0
0x7F is the classic ASCII "DEL" control character. It appears FreeRDP (in unicode keyboard mode) is sending the Delete key as a literal Unicode/ASCII character (0x7F) instead of as a proper virtual-key event, and Windows applications naturally can't render/interpret that as an actual Delete action — they either show it as an unprintable glyph or ignore it.
Interestingly, connecting to a full RDP desktop session (not seamless/RemoteApp) with the same /kbd:unicode flag does NOT reproduce the bug — Delete works fine there. The issue seems specific to FreeRDP's RemoteApp/seamless keyboard handling path combined with /kbd:unicode.
Workaround
Running an AutoHotkey v2 script inside the Windows VM that installs a low-level keyboard hook (WH_KEYBOARD_LL) and remaps this specific VK_PACKET+0x7F event back to a real Delete keypress fully restores normal Delete behavior without disabling /kbd:unicode:
#Requires AutoHotkey v2.0
#SingleInstance Force
Persistent
hookProc := CallbackCreate(LowLevelKeyboardProc, "F", 3)
hHook := DllCall("SetWindowsHookEx", "Int", 13, "Ptr", hookProc, "Ptr", 0, "UInt", 0, "Ptr")
OnExit((*) => DllCall("UnhookWindowsHookEx", "Ptr", hHook))
LowLevelKeyboardProc(nCode, wParam, lParam) {
static WM_KEYDOWN := 0x100, WM_KEYUP := 0x101, VK_PACKET := 0xE7
if (nCode >= 0) {
vkCode := NumGet(lParam, 0, "UInt")
scanCode := NumGet(lParam, 4, "UInt")
if (vkCode = VK_PACKET && scanCode = 0x7F) {
if (wParam = WM_KEYDOWN)
Send("{Delete down}")
else if (wParam = WM_KEYUP)
Send("{Delete up}")
return 1
}
}
return DllCall("CallNextHookEx", "Ptr", 0, "Int", nCode, "Ptr", wParam, "Ptr", lParam)
}
This may be related to #917, which also deals with /kbd:unicode side effects in MS Word, though that issue addresses layout switching rather than the Delete key specifically.
Your FreeRDP version and where you got it from
FreeRDP 3.31.1, from Fedora official repo (freerdp-3.31.1-1.fc44.x86_64)
Your Linux distribution and version
Fedora release 44 (Forty Four), KDE Plasma 6
Your winapps.conf
RDP_USER="REDACTED"
RDP_PASS="REDACTED"
WAFLAVOR="podman"
RDP_FLAGS="/kbd:unicode"
# RDP_FLAGS="/kbd:unicode" # working variant, but the Delete key does not work correctly (instead of deleting, it inserts a "square" placeholder character)
# RDP_FLAGS="/kbd:unicode /grab-keyboard" # working variant, but the Delete key does not work correctly (instead of deleting, it inserts a "square" placeholder character)
# RDP_FLAGS="/kbd:unicode /kbd:type:0x00000004" # Delete key works, but keyboard layout switching does not work
# RDP_FLAGS="/kbd:unicode /kbd:layout:0x00000409" # Delete key works, but keyboard layout switching does not work
# RDP_FLAGS="/grab-keyboard /cert:tofu" # Delete key works, but keyboard layout switching does not work
# RDP_FLAGS="/kbd:layout:0x00000409 /grab-keyboard /cert:tofu" # Delete key works, but keyboard layout switching does not work
# RDP_FLAGS="/kbd:type:0x00000004 /kbd:layout:0x00000409 /grab-keyboard /cert:tofu" # Delete key works, but keyboard layout switching does not work
# RDP_FLAGS="/kbd:type:0x00000004 /kbd:layout:0x00000409" # Delete key works, but keyboard layout switching does not work
Logs
Terms
What happened?
Description
When adding
RDP_FLAGS="/kbd:unicode"to winapps.conf (used to get consistent keyboard-layout-switching shortcuts across different host OSes, since without it the shortcut differs per OS), the Delete key stops performing its function inside seamless WinApps applications (tested in MS Word). Instead of deleting the character to the right of the cursor, an invalid/placeholder "tofu" square glyph is inserted into the document.This flag is not set by default — the issue only appears once the user manually enables /kbd:unicode. In my case, I enabled it specifically because the default keyboard-layout-switching shortcut (Ctrl+Shift) was not working reliably/consistently across different host OSes, and /kbd:unicode was the only combination that fixed layout switching — at the cost of breaking the Delete key as described below.
Expected behavior
Pressing Delete should delete the character to the right of the cursor, exactly as it does without
/kbd:unicodeenabled.Root cause (confirmed via Windows low-level keyboard hook)
Without
/kbd:unicode, pressing Delete produces a normal Windows key event:VK=0x2E (VK_DELETE) SC=0x53 Flags=0x1 (extended)
With
/kbd:unicodeenabled, in seamless/RemoteApp mode, pressing Delete instead produces:VK=0xE7 (VK_PACKET) SC=0x7F Flags=0x0
0x7F is the classic ASCII "DEL" control character. It appears FreeRDP (in unicode keyboard mode) is sending the Delete key as a literal Unicode/ASCII character (0x7F) instead of as a proper virtual-key event, and Windows applications naturally can't render/interpret that as an actual Delete action — they either show it as an unprintable glyph or ignore it.
Interestingly, connecting to a full RDP desktop session (not seamless/RemoteApp) with the same
/kbd:unicodeflag does NOT reproduce the bug — Delete works fine there. The issue seems specific to FreeRDP's RemoteApp/seamless keyboard handling path combined with/kbd:unicode.Workaround
Running an AutoHotkey v2 script inside the Windows VM that installs a low-level keyboard hook (WH_KEYBOARD_LL) and remaps this specific VK_PACKET+0x7F event back to a real Delete keypress fully restores normal Delete behavior without disabling
/kbd:unicode:This may be related to #917, which also deals with
/kbd:unicodeside effects in MS Word, though that issue addresses layout switching rather than the Delete key specifically.Your FreeRDP version and where you got it from
FreeRDP 3.31.1, from Fedora official repo (freerdp-3.31.1-1.fc44.x86_64)
Your Linux distribution and version
Fedora release 44 (Forty Four), KDE Plasma 6
Your
winapps.confLogs
Terms