qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] ps2: take exact use of ps2 buffer


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [PATCH] ps2: take exact use of ps2 buffer
Date: Thu, 02 Jun 2016 12:05:25 +0200

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 <address@hidden>
> 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]