[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. 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. 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. Did you see my other question abot either adding -kbddelay [duration=]msecs or merging it into -k (-k [language=]language[,delay=msecs]? Which would be the better approach? -- Dave Mielke | 2213 Fox Crescent | The Bible is the very Word of God. Phone: 1-613-726-0014 | Ottawa, Ontario | http://Mielke.cc/bible/ EMail: d...@mielke.cc | Canada K2A 1H7 | http://FamilyRadio.com/
