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
