From: Gerd Hoffmann <kraxel@redhat.com>
To: Yang Hongyang <hongyang.yang@easystack.cn>
Cc: Gonglei <arei.gonglei@huawei.com>,
qemu devel <qemu-devel@nongnu.org>,
Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] ps2: take exact use of ps2 buffer
Date: Thu, 02 Jun 2016 12:05:25 +0200 [thread overview]
Message-ID: <1464861925.24775.85.camel@redhat.com> (raw)
In-Reply-To: <CAN+wFuJ=VRYBxztu9CzzPCbOm4rNGLmSPUZ+s5YVB7Hwoxfb_Q@mail.gmail.com>
On Do, 2016-06-02 at 17:19 +0800, Yang Hongyang wrote:
> Hi Gerd,
> Thanks for reply!
>
>
> On Thu, Jun 2, 2016 at 4:37 PM, Gerd Hoffmann <kraxel@redhat.com>
> wrote:
> On Do, 2016-06-02 at 14:05 +0800, Yang Hongyang wrote:
> > According to PS/2 Mouse/Keyboard Protocol, the keyboard
> output buffer
> > size is 16 bytes, but we only use 15 bytes actually, this
> causes some
> > problem, for example, if I submit "123456789" in a bunch
> through VNC,
> > the actual result will be "12345678888888888...", because
> the 16th key
> > event which is "8" key up is dropped.
>
> What if you try a 10-char string next?
>
>
> Actually I've tested this patch, I submit multiple 10-char string,
> things work
> as expected, it only takes the first 8-char.
That is pure luck. It could have taken the first 9 chars in case the
guest manages to take one out of the queue while you are filling the
queue. It's a race and nothing you can depend on.
> The poin is not about to make it work with more then 8 string, it is
> to
> make it competible with the protocol, which is a 16-bytes
> buffer, apparantly
> we are not following this and which do cause the problem.
There is no such protocol.
On physical hardware things are working fine because you simply can't
type fast enough to overflow the buffer. On virtual hardware you can if
you script keyboard input, thereby breaking things, simply because ps/2
wasn't designed for that. Whenever the buffer is 15 bytes or 16 bytes
or something else (with usb-kbd) doesn't matter, the underlying issue is
always the same. And the solution is to apply a speed limit to kbd
input.
> This chunk of code originally uses full QUEUE_SIZE buffer, and in
> this commit 2858ab09e6f708e3, it changes the behaviour implicitly.
It's a workaround for older linux kernels. They misbehave in case they
find 16 chars in the ps2 buffer (this is something which simply doesn't
happen on real hardware).
cheers,
Gerd
next prev parent reply other threads:[~2016-06-02 10:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-02 6:05 [Qemu-devel] [PATCH] ps2: take exact use of ps2 buffer Yang Hongyang
2016-06-02 8:37 ` Gerd Hoffmann
2016-06-02 9:19 ` Yang Hongyang
2016-06-02 10:05 ` Gerd Hoffmann [this message]
2016-06-02 10:34 ` Yang Hongyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1464861925.24775.85.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=arei.gonglei@huawei.com \
--cc=hongyang.yang@easystack.cn \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).