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
