qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-trivial] patch: add delay=<msecs> suboption to -d


From: Gerd Hoffmann
Subject: Re: [Qemu-devel] [Qemu-trivial] patch: add delay=<msecs> suboption to -display curses
Date: Tue, 27 May 2014 11:09:46 +0200

On Di, 2014-05-27 at 04:15 -0400, Dave Mielke wrote:
> [quoted lines by Gerd Hoffmann on 2014/05/27 at 07:44 +0200]
> 
> >What exactly is the problem?
> 
> At the user level, the keyboard appears to be dead. An inspection of the 
> udnerlying code reveals that the application itsllf is querying the MS-DOS 
> keyboard input buffer in a bad way.

Which means exactly?  They are not prepared to find data for more than
one key event in the buffer?

> Those apps can't be fixed, though, because 
> the bad code is in a library which is statically linked into every app using 
> it, which means lots of apps, many of which, as is always the case, may not 
> even have source code anymore.

Sure.

> Another thing to consider is that this, really, is a general problem. Most 
> keyboard input code, especially in older days, would've nly ever been tested 
> at 
> typing speed. It should be expected, therefore, that there might be problems 
> in 
> some of it when input events arrive faster - in this case, "infinitely" 
> fater. 
> The solution I'm proposing, therefore, tackles it in a general way, and does 
> nothing more than allow the user to request that, regardless of what the UI 
> needs to do underneath, the keyboard events still arrive at the speed of a 
> typist.

I don't like the idea to do it in the UI code.  I don't think the
problem is as generic as you think it is.  HID keyboards (usb,
bluetooth) report keys in a completely different way, and probably your
problem is specific to the ps/2 keyboard.

I'd try to do it in the ps/2 code, and try to do it without a timer.

Idea:  Split the ps/2 keyboard queue into two.  One will be
guest-visible.  The existing ps2 queue will do the job.  The other, new
queue will not be visible to the guest.  Simliar to the queue you've
added to the ui code.  Put not more than one key event (1-3 scancodes)
into the guest visible queue.  Wait for the guest read the status
register (signaling "no more data") once.  Then go refill the
guest-visible queue from the invisible queue.  With some luck this makes
things work without a delay.

If not we are not so lucky we have to fire a timer for queue refill
after signaling "no more data" to the guest.  Even in case we need a
timer this is better than doing it in the ui code as we can arm the
timer when we know the guest has actually seen the key event.  So the
guest being busy with something else and not polling the kbd for a time
span longer than the delay will not break things, so we can use a pretty
short delay.

cheers,
  Gerd





reply via email to

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