Debian Bug report logs - #758881
qemu-system-x86: VNC server can't get all sent chars correctly

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Gabriele Giacone <1o5g4r8o@gmail.com>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: qemu-system-x86: VNC server can't get all sent chars correctly

Date: Fri, 22 Aug 2014 13:55:45 +0200

Package: qemu-system-x86
Version: 2.1+dfsg-3
Severity: normal

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).


-- 
G..e

Message #10 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Gabriele Giacone <1o5g4r8o@gmail.com>

To: 758881@bugs.debian.org

Subject: Re: Bug#758881: qemu-system-x86: VNC server can't get all sent chars correctly

Date: Sat, 23 Aug 2014 02:45:25 +0200

[Message part 1 (text/plain, inline)]

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.

-- 
G..e

[culprit (text/plain, attachment)]

Message #15 received at 758881@bugs.debian.org (full text, mbox, reply):

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

To: qemu-devel <qemu-devel@nongnu.org>

Cc: Gerd Hoffmann <kraxel@redhat.com>, Gonglei <arei.gonglei@huawei.com>, 758881@bugs.debian.org, Gabriele Giacone <1o5g4r8o@gmail.com>

Subject: [bisected] VNC server can't get all sent chars correctly

Date: Sat, 23 Aug 2014 12:56:03 +0400

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

Message #22 received at 758881@bugs.debian.org (full text, mbox, reply):

From: "Gonglei (Arei)" <arei.gonglei@huawei.com>

To: Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>

Cc: Gerd Hoffmann <kraxel@redhat.com>, "758881@bugs.debian.org" <758881@bugs.debian.org>, Gabriele Giacone <1o5g4r8o@gmail.com>

Subject: RE: [bisected] VNC server can't get all sent chars correctly

Date: Mon, 25 Aug 2014 03:19:59 +0000

Hi,

> From: Michael Tokarev [mailto:mjt@tls.msk.ru]
> Sent: Saturday, August 23, 2014 4:56 PM
> To: qemu-devel
> Cc: Gerd Hoffmann; Gonglei (Arei); 758881@bugs.debian.org; Gabriele
> Giacone
> Subject: [bisected] VNC server can't get all sent chars correctly
> 
> 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? :)
> 
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

Message #27 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Markus Armbruster <armbru@redhat.com>

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

Cc: qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Gabriele Giacone <1o5g4r8o@gmail.com>, Gerd Hoffmann <kraxel@redhat.com>, 758881@bugs.debian.org

Subject: Re: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

Date: Mon, 25 Aug 2014 09:30:00 +0200

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

> 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? :)

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().

Message #32 received at 758881@bugs.debian.org (full text, mbox, reply):

From: "Gonglei (Arei)" <arei.gonglei@huawei.com>

To: Markus Armbruster <armbru@redhat.com>, Michael Tokarev <mjt@tls.msk.ru>

Cc: qemu-devel <qemu-devel@nongnu.org>, Gabriele Giacone <1o5g4r8o@gmail.com>, Gerd Hoffmann <kraxel@redhat.com>, "758881@bugs.debian.org" <758881@bugs.debian.org>

Subject: RE: [Qemu-devel] [bisected] VNC server can't get all sent chars correctly

Date: Mon, 25 Aug 2014 07:36:24 +0000

> From: Markus Armbruster [mailto:armbru@redhat.com]
> Sent: Monday, August 25, 2014 3:30 PM
> To: Michael Tokarev
> Cc: qemu-devel; Gonglei (Arei); Gabriele Giacone; Gerd Hoffmann;
> 758881@bugs.debian.org
> Subject: Re: [Qemu-devel] [bisected] VNC server can't get all sent chars
> correctly
> 
> Michael Tokarev <mjt@tls.msk.ru> writes:
> 
> > 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? :)
> 
> 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

Message #37 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Gerd Hoffmann <kraxel@redhat.com>

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

Cc: qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, 758881@bugs.debian.org, Gabriele Giacone <1o5g4r8o@gmail.com>

Subject: Re: [bisected] VNC server can't get all sent chars correctly

Date: Mon, 25 Aug 2014 11:37:05 +0200

On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote:
> 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.

> 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).

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

Message #42 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Gabriele Giacone <1o5g4r8o@gmail.com>

To: Gerd Hoffmann <kraxel@redhat.com>, 758881@bugs.debian.org

Cc: Michael Tokarev <mjt@tls.msk.ru>, qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Marc Sibson <sibson+vncdotool@gmail.com>

Subject: Re: Bug#758881: [bisected] VNC server can't get all sent chars correctly

Date: Mon, 25 Aug 2014 12:40:01 +0200

[ CC'ing Marc Sibson, vncdotool developer ]

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

On Mon, Aug 25, 2014 at 11:37 AM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> On Sa, 2014-08-23 at 12:56 +0400, Michael Tokarev wrote:
>> 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.
>
>> 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).
>
> 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.

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,
-- 
G..e

Message #47 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Marc <sibson@gmail.com>

To: 758881@bugs.debian.org, Gabriele Giacone <1o5g4r8o@gmail.com>, Gerd Hoffmann <kraxel@redhat.com>

Cc: qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Michael Tokarev <mjt@tls.msk.ru>, Marc Sibson <sibson+vncdotool@gmail.com>

Subject: Re: Bug#758881: [bisected] VNC server can't get all sent chars correctly

Date: Mon, 25 Aug 2014 21:11:59 -0700

[Message part 1 (text/plain, inline)]

Hi,

On August 25, 2014 at 3:40:01 AM, Gabriele Giacone (1o5g4r8o@gmail.com) wrote:
> 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. 
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?

-- 

Marc

[Message part 2 (text/html, inline)]

Message #52 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Gerd Hoffmann <kraxel@redhat.com>

To: Marc <sibson@gmail.com>

Cc: 758881@bugs.debian.org, Gabriele Giacone <1o5g4r8o@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Michael Tokarev <mjt@tls.msk.ru>, Marc Sibson <sibson+vncdotool@gmail.com>

Subject: Re: Bug#758881: [bisected] VNC server can't get all sent chars correctly

Date: Tue, 26 Aug 2014 07:40:25 +0200

On Mo, 2014-08-25 at 21:11 -0700, Marc wrote:
> Hi,
> 
> 
> On August 25, 2014 at 3:40:01 AM, Gabriele Giacone
> (1o5g4r8o@gmail.com) wrote:
> > 
> > > 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. 
> 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

Message #57 received at 758881@bugs.debian.org (full text, mbox, reply):

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

To: Gerd Hoffmann <kraxel@redhat.com>, 758881@bugs.debian.org, Marc <sibson@gmail.com>

Cc: Gabriele Giacone <1o5g4r8o@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Marc Sibson <sibson+vncdotool@gmail.com>

Subject: Re: Bug#758881: [bisected] VNC server can't get all sent chars correctly

Date: Tue, 26 Aug 2014 09:55:22 +0400

26.08.2014 09:40, Gerd Hoffmann wrote:
> 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).

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

Message #62 received at 758881@bugs.debian.org (full text, mbox, reply):

From: Gerd Hoffmann <kraxel@redhat.com>

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

Cc: 758881@bugs.debian.org, Marc <sibson@gmail.com>, Gabriele Giacone <1o5g4r8o@gmail.com>, qemu-devel <qemu-devel@nongnu.org>, Gonglei <arei.gonglei@huawei.com>, Marc Sibson <sibson+vncdotool@gmail.com>

Subject: Re: Bug#758881: [bisected] VNC server can't get all sent chars correctly

Date: Tue, 26 Aug 2014 08:08:48 +0200

On Di, 2014-08-26 at 09:55 +0400, Michael Tokarev wrote:
> 26.08.2014 09:40, Gerd Hoffmann wrote:
> > 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).
> 
> 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?

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

Message #67 received at 758881@bugs.debian.org (full text, mbox, reply):

From: "Mrs. Mackenzie Scott" <jackjonhson209@gmail.com>

To: undisclosed-recipients:;

Subject: Federal Grant Approval

Date: Wed, 17 Feb 2021 09:01:58 -0800

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

Send a report that this bug log contains spam.