Problem
Follow-up to #3226 and #3509, not a blocker for merging #3509.
The opt-in --vnc-force-caps workaround addresses the reported QEMU punctuation problem by using vncdotool’s US-layout Shift mapping. It does not establish reliable text entry across keyboard layouts or remove server-specific keysym translation behavior. Users typing code, paths, or shell commands need predictable output without guessing which modifier workaround their server needs.
Desired outcome
Determine a supported keyboard-input contract for the Python computer-server VNC backend that distinguishes text entry from physical key input, documents layout assumptions, and preserves compatibility with ordinary RFB servers.
Investigation scope
- Evaluate QEMU’s extended key event capability and whether the current vncdotool integration can negotiate and send it.
- Establish how text is mapped to physical keys for the guest layout. Scancodes alone do not solve Unicode text entry or layout discovery; do not assume the extension is a universal typing fix.
- Compare an extension-based path with the existing keysym path and opt-in force-caps workaround. Record supported cases, limitations, dependency changes, and fallback behavior.
- Keep this scoped to the Python VNC keyboard backend; native Cua Driver and unrelated sandbox transports are out of scope.
Acceptance evidence
- A documented recommendation, including whether implementation is worthwhile and whether an RFC is required before changing public behavior or compatibility.
- Reproducible results against a real QEMU target for the original sample
Hello_World-42 (a>b) & {x|y} #~$ tail, plus representative US and non-US layout cases. Record client/server versions, guest layout, expected text, and observed text.
- Evidence for uppercase/lowercase, shifted punctuation, modifier combinations, and key release behavior; explicitly document unsupported text/layout cases.
- If implemented: focused capability-negotiation and fallback tests, and verification against a server without the extension so existing RFB behavior is preserved.
Existing work and status
#3226 already identifies extended key events as a possible longer-term direction; this issue separates that investigation from the narrow workaround in #3509. Open issues and PRs were searched for QEMU/VNC extended-key work; no dedicated active implementation was found.
The latest review of #3509 was at 61264eaec9746672cf20aa6eefe6573abf42a6b7. Its added tests cover configuration forwarding with mocked startup/provider/transport boundaries; that review did not independently verify real QEMU behavior. This issue records follow-up intake, not implementation selection.
Problem
Follow-up to #3226 and #3509, not a blocker for merging #3509.
The opt-in
--vnc-force-capsworkaround addresses the reported QEMU punctuation problem by using vncdotool’s US-layout Shift mapping. It does not establish reliable text entry across keyboard layouts or remove server-specific keysym translation behavior. Users typing code, paths, or shell commands need predictable output without guessing which modifier workaround their server needs.Desired outcome
Determine a supported keyboard-input contract for the Python computer-server VNC backend that distinguishes text entry from physical key input, documents layout assumptions, and preserves compatibility with ordinary RFB servers.
Investigation scope
Acceptance evidence
Hello_World-42 (a>b) & {x|y} #~$ tail, plus representative US and non-US layout cases. Record client/server versions, guest layout, expected text, and observed text.Existing work and status
#3226 already identifies extended key events as a possible longer-term direction; this issue separates that investigation from the narrow workaround in #3509. Open issues and PRs were searched for QEMU/VNC extended-key work; no dedicated active implementation was found.
The latest review of #3509 was at
61264eaec9746672cf20aa6eefe6573abf42a6b7. Its added tests cover configuration forwarding with mocked startup/provider/transport boundaries; that review did not independently verify real QEMU behavior. This issue records follow-up intake, not implementation selection.