diff options
| author | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
|---|---|---|
| committer | Christian Krinitsin <mail@krinitsin.com> | 2025-07-03 07:27:52 +0000 |
| commit | d0c85e36e4de67af628d54e9ab577cc3fad7796a (patch) | |
| tree | f8f784b0f04343b90516a338d6df81df3a85dfa2 /results/classifier/gemma3:12b/vnc/1502884 | |
| parent | 7f4364274750eb8cb39a3e7493132fca1c01232e (diff) | |
| download | qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.tar.gz qemu-analysis-d0c85e36e4de67af628d54e9ab577cc3fad7796a.zip | |
add deepseek and gemma results
Diffstat (limited to 'results/classifier/gemma3:12b/vnc/1502884')
| -rw-r--r-- | results/classifier/gemma3:12b/vnc/1502884 | 15 |
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 |