Dear Maintainer,

To reproduce it:

Install vncdo:
$ sudo apt-get install python-twisted python-imaging
$ git clone https://github.com/sibson/vncdotool
$ cd vncdotool/
$ sudo python setup.py install

$ curl -L -z linux -o linux http://ftp.it.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot/gtk/debian-installer/amd64/linux
$ curl -L -z initrd.gz -o initrd.gz http://ftp.it.debian.org/debian/dists/wheezy/main/installer-amd64/current/images/netboot/gtk/debian-installer/amd64/initrd.gz
$ sudo qemu-system-x86_64 -display vnc=localhost:10 -enable-kvm -cpu host -m 1024 -net nic,vlan=0 -net user,vlan=0,host=10.0.2.1,dhcpstart=10.0.2.2,dns=10.0.2.254 --kernel linux --initrd initrd.gz --append "locale=en_US keymap=us video=vesa:ywrap,mtrr vga=788" &

To follow installation:
$ gvncviewer localhost:10

Few seconds and install will stop at "Configure the network - Enter hostname"

Quit gvncviewer.

$ vncdo -s localhost:10 type "insecure"
[ "insecure" is current jenkins user password in g-i-installation jobs
at jenkins.debian.net]

$ gvncviewer localhost:10

Sometimes first "e" is not received ("inscure"), last one always gets
repeated as if "e" key was kept pressed, sometimes both.

Downgrading qemu to 2.0.0+dfsg-7, everything works fine.
Same behavior with backported packages, jenkins.d.n uses
wheezy-backports ones (2.1+dfsg-2~bpo70+2 KO, 2.0.0+dfsg-4~bpo70+1 OK).

Bisected.

  2858ab0 ps2: set ps/2 output buffer size as the same as kernel

I confirm problem vanishes by reverting it.
Attached one refreshed to apply upstream master.

There's a bug filed against debian qemu package, there:

http://bugs.debian.org/758881

which says about problems sending keypress events over VNC to
a qemu guest, -- some keypresses gets lost, at least.

The bisection between qemu 2.0 and 2.1 leads to this commit:

commit 2858ab09e6f708e381fc1a1cc87e747a690c4884
Author: Gonglei <arei.gonglei@huawei.com>
Date:   Thu Apr 24 20:06:19 2014 +0800

    ps2: set ps/2 output buffer size as the same as kernel

    According to the PS/2 Mouse/Keyboard Protocol, the keyboard outupt buffer size
    is 16 bytes. And the PS2_QUEUE_SIZE 256 was introduced in Qemu from the very
    beginning.

    When I started a  redhat5.6 32bit guest, meanwhile tapped the keyboard as quickly as
    possible, the screen would show me "i8042.c: No controller found". As a result,
    I couldn't use the keyboard in the VNC client.

    Previous discussion about the issue in maillist:
http://thread.gmane.org/gmane.comp.emulators.qemu/43294/focus=47180

    This patch has been tested on redhat5.6 32-bit/suse11sp3 64-bit guests.
    More easy meathod to reproduce:
    1.boot a guest with libvirt.
    2.connect to VNC client.
    3.as you see the BIOS, bootloader, Linux booting, run the follow simply shell script:
    for((i=0;i<10000000;i++)) do virsh send-key redhat5.6 KEY_A; done

    Actual results:
    dmesg show "i8042.c: No controller found." And the keyboard is out of work.

    Signed-off-by: Gonglei <arei.gonglei@huawei.com>
    Reviewed-by: Juan Quintela <quintela@redhat.com>
    Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>


So it looks like something else is not right here.  Before this patch,
it wasn't possible to use keyboard with VNC client with redhat 5 guest.
Now, it isn't possible to use keyboard with VNC in another scenario which
worked before (so it is a regression compared with 2.0 version).

What do we do with this? :)

Thanks,

/mjt

Hi,
I tested the same command line with the reported Bug, as below:

./qemu-system-x86_64 -vnc :10 -enable-kvm -cpu host -m 1024 --kernel \
/home/linux --initrd /home/initrd.gz --append "locale=en_US keymap=us \
video=vesa:ywrap,mtrr vga=788"

And the VNC client I tested are TightVNC and RealVNC.

But I could not reproduce this issue.

So, I think maybe vncdotool client once send too many characters
(and ps2 queue length > PS2_QUEUE_SIZE), which leading to some
characters are discarded by QEMU. More test cases will be useful IMHO.

Best regards,
-Gonglei

Michael Tokarev <mjt@tls.msk.ru> writes:

Suggest to add a tracepoint to the place that drops keystrokes due to
buffer being full, to verify that's really what happens.  Quick glance
at the code suggests ps2_queue().

+1  :)

Best regards,
-Gonglei

qemu 2.1 hardware emulation is more correct (ps/2 kbd queue size being
16 bytes instead of 256, matching real hardware).  That may trip up
software depending on old, broken behavior.

IMO vncdotool should be fixed to add small delays between keyboard
events, as if a real person is typing, instead of sending the key events
at the maximum possible speed.

I'm sure you can hit the issue with qemu 2.0 too, you just need longer
user input strings to trigger it, so it is less likely to happen.

cheers,
  Gerd

[ CC'ing Marc Sibson, vncdotool developer ]

Hi Marc, thread starts at
http://thread.gmane.org/gmane.comp.emulators.qemu/292614

I do confirm some chars don't get received with qemu 2.0 as well, e.g.
by sending "insecureinsecure": received string is "ecure", first 11
missing.

Thanks,

Hi,
vncdotool does have a —delay=MILLISECONDS switch that inserts a delay between commands.  Currently, the two behaviours causing trouble seem to be that delay defaults to 0 and "type insecure” is considered one command, so there is  no delay between key presses :(  

Is there a non-zero value for —delay that makes sense?  I’m somewhat hesitant to change —delay  as it would be a behavioural change for other users, but if the value is sufficiently small it could be a net usability gain.

Are you requesting that the type command be fixed to insert delays after every character or that default for —delay should be non-zero?

There should be a delay after every character.  It can be pretty small.
10ms should be enough (you should set TCP_NODELAY though to make sure
the key events are not buffered in the network stack).

I guess it makes sense to decouple that from the delay between commands
as the time a qemu guest needs to process a command can be much higher
than the time it needs to process a key event.

cheers,
  Gerd

26.08.2014 09:40, Gerd Hoffmann wrote:

Is this delay qemu-specific (or, rather, virtualization-specific, so to say,
when the target - the VNC server - is working with a hardware being emulated),
or applies to all VNC servers equally?

/mjt

Dunno, didn't try.  Maybe you can hit it with xvnc too.  But I'd expect
that software (xvnc) has larger buffers than (emulated) hardware, so it
doesn't trigger that easily.

cheers,
  Gerd

Good day,

l believe you are doing great and staying safe right, may the peace of
God be with you and your family, i know it will be a great surprise
reading from me today but consider this a divine intervention, if you
need any financial assistance you should get back at me.


Thank you.

Mrs. Mackenzie Scott
Email: mackenziescott65@gmail.com
Website:	bystanderrevolution.org