summary refs log tree commit diff stats
path: root/results/classifier/gemma3:12b/vnc/1502884
diff options
context:
space:
mode:
Diffstat (limited to 'results/classifier/gemma3:12b/vnc/1502884')
-rw-r--r--results/classifier/gemma3:12b/vnc/150288415
1 files changed, 15 insertions, 0 deletions
diff --git a/results/classifier/gemma3:12b/vnc/1502884 b/results/classifier/gemma3:12b/vnc/1502884
new file mode 100644
index 000000000..0c43728a8
--- /dev/null
+++ b/results/classifier/gemma3:12b/vnc/1502884
@@ -0,0 +1,15 @@
+
+Super important feature req: QEMU VNC server: Introduce a keyboard "norepeat" option!
+
+Hi,
+
+A big issue when using QEMU's VNC server (VNC KVM) is that, when there's a network lag, unintended keypresses go through to the QEMU guest VM.
+
+This is frequently "enter" keypresses, causing all kinds of unintended consequences in the VM. So basically it's extremely dangerous.
+
+This is because the VNC protocol's keyboard interaction is implemented in terms of key down - key up events, making the server's keyboard autorepeat kick in when it should not.
+
+
+For this reason, it would be great if QEMU's VNC server part would be enhanced with an option such that when a VNC protocol key down is received, then locally that is treated as one single keypress only (I don't know how that should be implemented but I guess either as an immediate key down - key up sequence locally, or key down + key up after say 0.05 seconds), instead of waiting for the key up event from the VNC client.
+
+Thanks!
\ No newline at end of file