Alan, I tried that just now. It didn't make any difference... which makes perfect sense.
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 processed again... Harold > -----Original Message----- > From: Alan Hourihane [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 19, 2002 4:33 PM > To: Harold Hunt > Cc: xoncygwin-devel; cygx > Subject: Re: MI keyboard input - automatic repeat? > > > Harold, > > 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). > > Alan. > > 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 [3]? > > > > 4) Is someone willing to rework the keyboard input code to more closely > > follow the VNC input code? > > > > > > That's all for now, > > > > Harold
