On 25 May 2014 00:29, Dave Mielke <d...@mielke.cc> wrote: > The attached patch (qemu-curses-delay-1.patch) allows the user to specify that > he needs -display curses to insert a delay in between key events. The current > behaviour is that it inserts key events immediately, one right after another, > which has proven to be too fast for some applications. Please let me know if > there are any improvements you'd like me to make to this patch, with the goal > that I'm hoping you'll accept it. A more detailed description of this patch is > as follows: > > Add support for the "-display curses" option to accept suboptions (-display > curses[,option...), and add the "delay=<msecs>" suboption. This suboption > causes a millisecond-based delay to be inserted in between key events so that > they won't be inserted immediately one after another. The delay is performed > using a qemu virtual clock timer. If the "delay" option isn't specified, or if > "delay=0" is specified, then the timer isn't used, thus making the default be > the original behaviour. The "=<msecs>" operand is optional - if it isn't > specified then 20 is assumed.
Why is this a problem only for the curses UI frontend, and not for any of the other UIs which might send key events? thanks -- PMM
