[PATCH] winex11.drv: Also send input events when the keymap state has changed

[Rémi Bernon]

On 8/7/19 5:19 PM, Zebediah Figura wrote:
> On 8/7/19 8:44 AM, Rémi Bernon wrote:
>> When pressing Alt-Tab for example, the application receives the KeyPress
>> event for Alt key before losing focus, but when focusing it back it
>> never receives the corresponding KeyRelease event and this can lead to
>> incorrect key state for applications listening on WM_SYSKEYUP/DOWN
>> messages, or for applications that use dinput keyboard device which is
>> implemented with the corresponding low-level keyboard hooks messages.
>>
>> When focus is gained back the application receives a KeymapNotify to
>> indicate the full keyboard state, and this can be used to make up for
>> the missing KeyRelease events.
>>
>> Signed-off-by: Rémi Bernon <rbernon at codeweavers.com>
>> ---
> 
> When writing tests for 1bc9c4fdb I came to the conclusion that Windows 
> doesn't send window messages in this case. Low-level hooks may be a 
> different matter. I guess this change is not likely to break anything 
> per se, but it's not strictly correct either.
> 
> 

Indeed, but it's not specific to this change. When comparing with 
Windows I could see that keyboard messages and low level hooks behave a 
little differently on Wine:

Pressing Alt alone:
* On Windows, it triggers repeated low-level WM_SYSKEYDOWN and 
WM_SYSKEYDOWN messages.
* On Wine, it triggers only once a low-level WM_SYSKEYDOWN and a 
WM_SYSKEYDOWN message.

Releasing Alt alone:
* On Windows, it triggers a low-level WM_KEYUP and a WM_SYSKEYUP message.
* On Wine, it triggers a WM_SYSKEYUP low-level and message, and a 
WM_KEYUP low-level and message.

Also, low-level hooks are called on Windows even if the application is 
in background, they aren't on Wine. This means that when focus is 
restored from Alt-Tab, there's a WM_KEYUP low-level hook call on Windows 
that is missing on Wine.

This could be another way to fix the issue here, as the low-level hook 
call would make dinput update it state correctly. Listening to 
background keyboard X11 events however would require to subscribe to 
xinput2 events, which is currently considered optional and only 
activated when cursor clipping is active (so only on foreground 
windows). The raw input patch series could help by making xinput2 active 
all the time, but it would still be optional.
-- 
Rémi Bernon <rbernon at codeweavers.com>