Re: Patch for keyboard handling
Harold, 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. The all points are right. I think you completely understand this patch. The essential difference between the old code and this patch is to remember states by ourselves or to peek in the internal states if necessary. Moreover, the old code refers the states of Windows which is not guaranteed to same as the XWin's states. Hence I believe the patch is, at least, not worse than the old code, though there remains some incompleteness. One is the event queue you told, another is cooperation with customized keyboards. 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. winRestoreModeKeyStates is called from WM_SETFOCUS handlers in winTopLevelWindowProc (in -multiwindow case) and winWindowProc (in other cases). Only 2 places. I hope this helps your review. Takuma Murakami ([EMAIL PROTECTED])
Re: Patch for keyboard handling
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
Re: Patch for keyboard handling
Harold, Actually, now I am a little doubtful that this patch is complete. If I recall correctly, we are merely enqueueing input events into a queue that the mi layer processes later. Checking the mode key states within the X server will only indicate what the mi layer currently knows about the mode key states. The my layer would not know that there are messages in its queue that change the state of the mode keys. 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. I also recall that there is a way to force the mi layer to process all input events (miProcessInputEvents ?) and that this could be called before querying the state of the mode key states in order to get a consistent result. 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. Takuma Murakami ([EMAIL PROTECTED]) xwin.kbd2.patch Description: Binary data
Re: Patch for keyboard handling
Takuma Murakami wrote: I have made a patch to improve keyboard handling. Any comments would be appreciated. The changes are: 1) win.h, winkeybd.c, winwndproc.c - Improve the synchronization of mode key states between XWin and Windows. + /* Stored to get internal mode key states. Must be read-only. */ + static unsigned short *g_winInternalModeKeyStatesPtr = NULL; Shouldn't this be a pointer to constant data? Isn't that: static unsigned short const * g_winInternalModeKeyStatesPtr = NULL; ??? 2) winmultiwindowwndproc.c - Enable mode key synchronization in -multiwindow mode. + g_winInternalModeKeyStatesPtr = (pDeviceInt-key-state); Wow! That is a really good idea. I should have been doing that all along, but I didn't realize that I could access the internal mode-key states. Great idea. 3) winwndproc.c - Make clean termination on logoff or shutdown. Good catch for WM_ENDSESSION. That should have been there all along... 4) winconfig.c - Fix the lacks of KEYUP messages in Japanese environments. The solution was proposed by Kensuke Matsuzaki. Looks good to me. It all depends on if it works for you guys. 5) winwndproc.c - Ignore Windows keyboard auto-repeats so that XWin controls auto-repeats instead of Windows. Okay. I will try to apply this patch tomorrow. Thanks for contributing, Harold
Re: Patch for keyboard handling
+ /* Stored to get internal mode key states. Must be read-only. */ + static unsigned short *g_winInternalModeKeyStatesPtr = NULL; Shouldn't this be a pointer to constant data? Isn't that: static unsigned short const * g_winInternalModeKeyStatesPtr = NULL; ??? Exactly. That's what I wanted to do. Thank you for pointing out. Takuma Murakami ([EMAIL PROTECTED])
Re: Patch for keyboard handling
Takuma Murakami wrote: I have made a patch to improve keyboard handling. Any comments would be appreciated. The changes are: 1) win.h, winkeybd.c, winwndproc.c - Improve the synchronization of mode key states between XWin and Windows. 2) winmultiwindowwndproc.c - Enable mode key synchronization in -multiwindow mode. Actually, now I am a little doubtful that this patch is complete. If I recall correctly, we are merely enqueueing input events into a queue that the mi layer processes later. Checking the mode key states within the X server will only indicate what the mi layer currently knows about the mode key states. The my layer would not know that there are messages in its queue that change the state of the mode keys. I also recall that there is a way to force the mi layer to process all input events (miProcessInputEvents ?) and that this could be called before querying the state of the mode key states in order to get a consistent result. Please respond to this either with a rebuttal or a different patch. I don't think I can commit the existing patch until then. Harold
