MI keyboard input - automatic repeat?
Tue Feb 19 14:32:00 GMT 2002
I tried that just now. It didn't make any difference... which makes perfect
If you think about it, when a Windows message (keyup/keydown) is processed,
it gets removed from the Windows message queue, regardless of whether X
actually processes the resulting input event before the next Windows
messages is read. I mean, you could pump the Windows messages queue in any
location you wanted to and it would never cause a processed message to be
> -----Original Message-----
> From: Alan Hourihane [mailto:firstname.lastname@example.org]
> Sent: Tuesday, February 19, 2002 4:33 PM
> To: Harold Hunt
> Cc: xoncygwin-devel; cygx
> Subject: Re: MI keyboard input - automatic repeat?
> Try disabling the BlockHandler, and leave input processing to the
> WakeupHandler. (you should be able to remove the blockhandler code
> actually - it may be entering two strokes into the input queue).
> On Tue, Feb 19, 2002 at 04:05:28PM -0500, Harold Hunt wrote:
> > In regards to some users noticing duplicate key strokes upon
> switching into
> > and out of Cygwin/XFree86...
> > Do the MI keyboard input routines have some sort of automatic key repeat
> > feature?
> > I have noticed the following behavior with the Native GDI
> engine, which is
> > extremely slow:
> > 1) Open an xterm
> > 2) Run 'xdpyinfo' to generate a few screens of output
> > 3) Scroll xterm to the top of the output
> > 4) Type 'exit' in the xterm. This causes xterm to
> automatically scroll back
> > to the user input line, which takes a few seconds.
> > 5) Notice that the xterm command line is 'eexit' not 'exit'.
> > 6) This isn't a problem with xterm echoing part of the command late...
> > because if you press enter you get an error about 'eexit' not
> being found.
> > 7) A similar sort of behavior can be exhibited by typing 'ls'
> followed by
> > enter. In this case it takes 'ls' a second or two to do the directory
> > listing; when the listing is finished the xterm display two
> command lines
> > instead of just one (an extra enter causes the first one to
> execute nothing,
> > so a second one then appears).
> > I believe that this behavior is due to the MI keyboard input
> code looking at
> > the lag between the 'e' and 'enter' presses and releases, then
> it probably
> > is dividing by some sort of key-repeat interval to determine
> how many key
> > strokes to actually send. This would also cause the extra keystrokes on
> > switching into and out of Cygwin/XFree86 that some people have noticed.
> > Perhaps this functionality isn't part of MI at all... rather,
> it may be part
> > of a lower level that reads the input event queue that MI generates.
> > The VNC project's method of handling user input is starting to
> make a lot
> > more sense:
> > 1) Ignore WM_KEYUP/WM_SYSKEYUP messages.
> > 2) In WM_KEYDOWN/WM_SYSKEYDOWN messages - discard mode key presses (Alt,
> > Ctrl, AltGr, Shift, etc.)
> > 3) In WM_KEYDOWN/WM_SYSKEYDOWN messages - read the mode key states, send
> > down events for each pressed mode key, send the actual key down
> event, send
> > the actual key up event, then send key up events for each of the pressed
> > mode keys.
> > That system prevents the delay between processing the key down
> and key up
> > events from causing duplicate key presses when the server is very busy
> > between the key being pushed and the key being released.
> > What I need to know is:
> > 1) Does this make sense to the other developers?
> > 2) Is there actually some mechanism in X that is causing the
> simulated key
> > repeats?
> > 3) Is there a way to disable any such mechanism in ?
> > 4) Is someone willing to rework the keyboard input code to more closely
> > follow the VNC input code?
> > That's all for now,
> > Harold
More information about the Cygwin-xfree