From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1811 invoked by alias); 5 Nov 2003 21:22:58 -0000 Mailing-List: contact cygwin-xfree-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-xfree-owner@cygwin.com Mail-Followup-To: cygwin-xfree@cygwin.com Reply-To: cygwin-xfree@cygwin.com Received: (qmail 1804 invoked from network); 5 Nov 2003 21:22:57 -0000 Received: from unknown (HELO sys02.mail.msu.edu) (35.9.75.102) by sources.redhat.com with SMTP; 5 Nov 2003 21:22:57 -0000 Received: from office.ixn.com ([68.23.74.57] helo=msu.edu) by sys02.mail.msu.edu with asmtp (Exim 4.10 #3) (TLSv1:RC4-MD5:128) id 1AHV7A-0008zF-00 for cygwin-xfree@cygwin.com; Wed, 05 Nov 2003 16:22:56 -0500 Message-ID: <3FA96A30.8090005@msu.edu> Date: Wed, 05 Nov 2003 21:22:00 -0000 From: Harold L Hunt II User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: cygwin-xfree@cygwin.com Subject: Re: Patch for keyboard handling References: <20031103163010.840F.MURAKAMI@ipl.t.u-tokyo.ac.jp> <3FA71169.7060805@msu.edu> <20031104175955.34AB.MURAKAMI@ipl.t.u-tokyo.ac.jp> In-Reply-To: <20031104175955.34AB.MURAKAMI@ipl.t.u-tokyo.ac.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00068.txt.bz2 List-Id: 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