This is the mail archive of the
cygwin-xfree@cygwin.com
mailing list for the Cygwin XFree86 project.
Re: MI keyboard input - automatic repeat?
- From: Alan Hourihane <alanh at fairlite dot demon dot co dot uk>
- To: Harold Hunt <huntharo at msu dot edu>
- Cc: xoncygwin-devel <xoncygwin-devel at lists dot sourceforge dot net>,cygx <cygwin-xfree at cygwin dot com>
- Date: Tue, 19 Feb 2002 21:32:48 +0000
- Subject: Re: MI keyboard input - automatic repeat?
- References: <NHEELHJHHFKPMAEAFMFCCEPNCLAA.huntharo@msu.edu>
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