Diagnosed with Claude

Summary

When the in-game Steam overlay's on-screen keyboard (OSK) is open over a Proton game, an X11 input grab is established (apparently tied to an invisible proxy window) that is never correctly released or forwarded to the actual game window. As a result:

1. Text typed via the on-screen keyboard never reaches the game's focused text field.
2. Physical keyboard input also fails to reach the game while the OSK is open — not just the virtual keyboard.
3. Mouse clicks cannot return focus to the game window while the OSK is open (consistent with an active grab, not just misdirected focus).
4. Closing the OSK immediately and reliably restores normal keyboard/mouse interaction with the game.

This reproduces with a Windows/Proton build of a game but not with the same game's native Linux build, run side-by-side on the same system — strongly suggesting the bug is in how the overlay negotiates input grab/focus specifically with a Wine/XWayland window, not a general X11 or KDE issue, and not a game-specific bug.

System Information

• Distro: Bazzite (Fedora Atomic/Kinoite-based), version 44.20260721.0
• Kernel: 7.1.3-ogc5.1.fc44.x86_64
• Desktop: KDE Plasma 6.7.3, KWin 6.7.3
• Session type: Reproduces on both a Wayland session (game running under XWayland) and a plain X11 session
• Steam build ID: 1785187029
• Proton versions tested: GE-Proton11-3, GE-Proton10-34, and stock Proton 7 — all reproduce identically
• Game used to reproduce: Stardew Valley (App ID 413150) — chosen because it ships both a Proton/Windows build and a native Linux build, allowing a direct side-by-side comparison on identical hardware/session

Steps to Reproduce

1. Launch a Proton game that has an in-game text field (e.g. Stardew Valley's character-naming screen).
2. Open the Steam overlay on-screen keyboard over that text field (via controller shortcut or overlay).
3. Type using the OSK.
4. Observe: no characters appear in the text field, despite the OSK itself visually registering each keypress.
5. Without closing the OSK, try typing on a physical keyboard instead.
6. Observe: physical keyboard input also fails to reach the field.
7. Try clicking directly on the game window.
8. Observe: click does not return focus/control to the game.
9. Close the OSK (its own close control).
10. Observe: keyboard and mouse interaction with the game are immediately restored to normal.

Expected Behavior

Typed text (via OSK or physical keyboard) should appear in the focused game text field, the same way it does for the same game's native Linux build.

Actual Behavior

No text reaches the field, and input is effectively locked away from the game window until the OSK is closed.

Diagnostic Evidence

This was traced down to the X11 protocol level rather than guessed at:

• xev attached directly to the game's actual X window (confirmed via matching _NET_WM_PID) shows valid KeyPress/KeyRelease events with correct XLookupString character translation arriving at the window when typing on a physical keyboard — ruling out a simple "events never sent" explanation in isolation.
• WINEDEBUG=+key,+win,+event,+focus,+message on the Proton build shows the physical keyboard path working perfectly end-to-end: X11DRV_KeyEvent (raw X11 key event) → VK code conversion → WM_KEYDOWN → WM_CHAR → WM_KEYUP, all correctly dispatched to the game's real HWND. In the same capture, the OSK's keypresses never once reach X11DRV_KeyEvent — the only trace of the OSK's key at all is a X11DRV_ToUnicodeEx call against window 0 with incrementing keyboard-state arguments, consistent with a layout/character lookup rather than a delivered key event.
• With the OSK open, real X server input focus (queried via XGetInputFocus, i.e. xdotool getwindowfocus) is on an invisible 1×1, InputOnly, override-redirect window with no name and no _NET_WM_PID — not on the game's window. override-redirect windows are explicitly excluded from window-manager policy by X11 design, consistent with this being a raw grab/proxy window created by the overlay itself rather than anything KWin manages.
• This also explains why physical keyboard input fails only while the OSK is open: X11 delivers any key event — synthetic or real hardware — to whichever window currently holds focus/grab. With the grab parked on the phantom window, both input sources are equally misdirected.
• A KWin window rule (e.g. forcing "Accept Focus") was tested against the game window and had no effect, consistent with this being a client-held input grab rather than a window-manager focus-assignment issue that a compositor-side rule could influence.

Why this may be under-reported

This appears specific to desktop KDE Plasma/XWayland sessions running Proton, as opposed to:

• Steam Deck/SteamOS, which uses gamescope — a different, Valve-controlled compositor where this grab/focus negotiation may be implemented differently (or not present at all).
• Other desktop environments, which may negotiate input grabs with the overlay differently.

That would make this a real but narrow intersection (desktop KDE + Proton + attempting keyboard text entry), rather than a universal Proton input bug, which is consistent with it not being a widely-flagged issue despite being 100% reproducible here.

Additional Notes

Happy to provide the full xev and WINEDEBUG logs, or run further tests, on request.

excerpt_winedebug_stardew.txt
excerpt_xev_stardew.txt