On Jun 14, 2011, at 12:40 AM, Vincent Povirk wrote:
Is it necessary to test QS_HOTKEY in dlls/winex11.drv/event.c:filter_event, where QS_KEY is currently tested? If somebody calls MsgWaitForMultipleObjectsEx with QS_HOTKEY but not QS_KEY, shouldn't KeyPress events be accepted?
I guess? Wouldn't we have to actually set QS_HOTKEY before that does any good?
You mean your patch 5? Well, it's a bit of a chicken-and-egg situation. I don't think it matters much which order the two things are added. They'll both ultimately be necessary. In some sense, doing winex11.drv first makes sense, since it's the first "gate" for the event to make it into the system. (Admittedly, it's probably very unlikely that MsgWaitForMultipleObjectsEx will be called with QS_HOTKEY and not QS_KEY.)
You may be able to use the non-left-right-sensitive vkeys (e.g. VK_MENU) here, and thus eliminate the alt_vkey parameter. And if you can't, then update_modifier_state doesn't do the right thing when alt_vkey is the one that's pressed in the keystate but it's no longer pressed in event->state. In that case, you send a key-up for vkey, when you should send it for alt_vkey. If both were down and now neither is, you'll need to send a key-up for both. Note, to send keyboard input for a right-hand modifier, you'll need to include KEYEVENTF_EXTENDEDKEY in the flags and different scan codes.
There's no such combined vkey for the windows key. Even if there were, releasing VK_MENU when VK_LMENU was pressed doesn't seem like a good idea.
I was thinking that maybe the send-input machinery would take a side-generic key and do the right thing. A little more research reveals that it doesn't. However, that still leaves you doing the wrong thing with your side-sensitive code. If event->state doesn't include MetaMask, then you send a key-up for VK_LMENU when it may have been VK_RMENU that was previously down. You need to send a key-up for whichever was previously down, and that might even be both. Note that the important thing is not that you have sent a key event for the wrong key, it's that you haven't properly transitioned to a state which matches event->state. That is, you sent the key-up but the overall key state will still have a menu key down.
Now you've got me worried about what happens when we press VK_LWIN and it later turns out VK_RWIN was really pressed (and has been released). :/
For when you send a key-down, it's not so important. In that case, you're properly transitioning from neither being down to at least one of them being down. If it later turns out that you synthesized a VK_LWIN-down when the user had actually pressed VK_RWIN, then that will get corrected on the next KeymapNotify.
-Ken
-
Ken Thomases