From: Yang Hongyang <hongyang.yang@easystack.cn>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Yang Hongyang <hongyang.yang@easystack.cn>,
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, 2 Jun 2016 18:34:31 +0800 [thread overview]
Message-ID: <CAN+wFuLhoeF0x5ps6yVsEjSVP-kRmZ+vGy9RgTtU2FKP5jn8Ww@mail.gmail.com> (raw)
In-Reply-To: <1464861925.24775.85.camel@redhat.com>
On Thu, Jun 2, 2016 at 6:05 PM, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 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.
>
Thanks for the explaination, I got your point, by add the speed limit to kbd
input, even when I send a bulk kbd event through vnc, the kbd will have
time to
read the data. before this, vnc will fulfill the buffer until qemu have
time to to schedule a kbd_read_data call. I've tested your patch, and it
solved my problem, thank you.
>
> > 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
>
>
>
>
--
Thanks,
Yang
prev parent reply other threads:[~2016-06-02 10:34 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
2016-06-02 10:34 ` Yang Hongyang [this message]
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=CAN+wFuLhoeF0x5ps6yVsEjSVP-kRmZ+vGy9RgTtU2FKP5jn8Ww@mail.gmail.com \
--to=hongyang.yang@easystack.cn \
--cc=arei.gonglei@huawei.com \
--cc=kraxel@redhat.com \
--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).