[Linux] @ / shifted symbols from mobile soft keyboards clear the text field (UTF-8 input via Ctrl+Shift+U)

[OMGrant]

Describe the bug

On a Linux host, typing certain characters from a mobile Moonlight client's on-screen keyboard (e.g. Android Gboard) clears/corrupts the target text field instead of inserting the character. The most reliable trigger is @. This makes things like logging into a website over a Moonlight desktop stream very difficult.

Steps to reproduce

1. Host: Linux, KDE Plasma 6 (Wayland), US keyboard layout, Sunshine v2026.516.143833.
2. Client: Moonlight Android, using Gboard.
3. Stream the desktop and focus a text field (e.g. Chrome's address bar).
4. Type test@.

Expected behavior

test@ appears in the field.

Actual behavior

The @ clears/corrupts the field. Letters that arrive as keycodes type fine; only the symbol does this.

Root cause (from debug logs)

With min_log_level = 1, typing @ logs:

--begin unicode packet--
text [@]
--end unicode packet--
Unicode, typing U+40

Gboard commits @ as UTF-8 text, so it arrives as a UTF8_TEXT packet rather than a keycode. On Linux, platf::keyboard::unicode() (src/platform/linux/input/inputtino_keyboard.cpp) types UTF-8 via the IBus/GTK Ctrl+Shift+U + hex-codepoint method. That method is only honored by IBus-enabled apps; in Chrome / KDE / Wayland-native apps / password fields the leading Ctrl chord is interpreted as a shortcut (e.g. Ctrl+U) and clears the field.

For contrast, the same @ when it arrives as a keycode works correctly:

keyCode [8032]  (VK_2)   modifiers [01]  (Shift)

So the keycode+Shift path is fine; only the UTF-8 text path is broken.

Environment

• Host OS: Nobara Linux 43 (KDE Plasma 6.6.4, Wayland)
• Host keyboard layout: us
• Sunshine: v2026.516.143833
• Client: Moonlight Android + Gboard

Possible fix

Inject printable ASCII as real keystrokes (on a US layout @ -> Shift+2) and keep the Ctrl+Shift+U method only for genuine non-ASCII. A fully layout-independent fix would resolve each codepoint against the active keymap via libxkbcommon. (A draft patch and reviewer discussion of the US-layout caveat are in #5273.)