public inbox for cygwin-xfree@sourceware.org
help / color / mirror / Atom feed
From: Harold L Hunt II <huntharo@msu.edu>
To: cygwin-xfree@cygwin.com
Subject: Re: Patch for keyboard handling
Date: Wed, 05 Nov 2003 21:22:00 -0000	[thread overview]
Message-ID: <3FA96A30.8090005@msu.edu> (raw)
In-Reply-To: <20031104175955.34AB.MURAKAMI@ipl.t.u-tokyo.ac.jp>

Takuma,

Takuma Murakami wrote:

> I agree with you.  If the mi event queue has pending
> events when winRestoreModeKeyStates is called, it may
> fail to synchronize mode key states between XWin and
> Windows.  However, the new code can re-sync them at
> the next time winRestoreModeKeyStates is called while
> it is hard to do for the old code.

Okay.

> Thank you for your suggestion.  mieqProcessInputEvents
> seems to do the work.  I inserted a code to call it
> and it looks working well for now, though I don't sure
> if it is legal to call it from the place other than
> ProcessInputEvents.
> 
> The attached is a revised patch to call the function.
> I deeply appreciate your feedback.

Looks good, but I think you are right about some danger in calling 
mieqProcessInputEvents.

Hmm... the problem with calling ProcessInputEvents or 
mieqProcessInputEvents from our keyboard processing is that it causes 
input events to be processed one at a time, instead of in a queue.  It 
completely negates the purpose of having an input queue in the X layer.


I think I understand your original patch better now and I think that you 
were probably doing it correctly, but I can't verify that right now.  If 
this is what you were trying to do, then it probably is correct:

1) Assume that no keyboard input is in the mi queue when winWindowProc 
is called.

2) If we are getting the keyboard focus, grab the Windows mode key state 
and X mode key state, compare them, and send fake key presses to X to 
get the two states in synch.

3) Do not synch the key states anywhere else.

That would probably work because it would enqueue key messages that will 
synch the mode key states before placing normal key messages in the 
queue.  Thus, when we ask X for the mode key states we should get a 
consistent result since the input queue in X is empty.

Does that sound like what you were trying to do initially?  I got 
confused because I couldn't keep track of where all the calls to 
winRestoreModeKeyStates would up.

Let me know,

Harold


  reply	other threads:[~2003-11-05 21:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-03  8:25 Takuma Murakami
2003-11-03 14:30 ` Harold L Hunt II
2003-11-03 15:05   ` Takuma Murakami
2003-11-04  2:39 ` Harold L Hunt II
2003-11-04  9:04   ` Takuma Murakami
2003-11-05 21:22     ` Harold L Hunt II [this message]
2003-11-07  9:57       ` Takuma Murakami

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3FA96A30.8090005@msu.edu \
    --to=huntharo@msu.edu \
    --cc=cygwin-xfree@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).