[PATCH v2 0/1] MR9737: win32u: Process every driver event in NtUserGetAsyncKeyState.

[Rémi Bernon (＠rbernon)]

Splinter Cell sends WM_SETREDRAW 0 which changes the window style,
removing WS_VISIBLE, then SetWindowPos and WM_SETREDRAW 1 right after
that, then stops processing or waiting on window messages entirely while
playing its intro video. The only call it does is GetAsyncKeyState, to
check whether mouse buttons are pressed to skip its intro videos.

In winex11 we now request window state changes asynchronously and in
particular we request WM_STATE Withdrawn in this case when SetWindowPos
is called after removing WS_VISIBLE.

When WM_SETREDRAW 1 is called we also try updating the window state as
it should be made visible again, but this often happens too quickly and
the window manager hasn't yet updated the WM_STATE property, so we delay
the request until a later call to WindowPosChanged or until the reply is
received.

As the game doesn't process its window messages, ProcessEvents is then
never called with the right mask and the WM_STATE update is never seen.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069

--
  v2: win32u: Process every driver event in NtUserGetAsyncKeyState.
 
https://gitlab.winehq.org/wine/wine/-/merge_requests/9737

[PATCH v2 1/1] win32u: Process every driver event in NtUserGetAsyncKeyState.

[Rémi Bernon]

From: Rémi Bernon <[e-mail]>

Splinter Cell sends WM_SETREDRAW 0 which changes the window style,
removing WS_VISIBLE, then SetWindowPos and WM_SETREDRAW 1 right after
that, then stops processing or waiting on window messages entirely while
playing its intro video. The only call it does is GetAsyncKeyState, to
check whether mouse buttons are pressed to skip its intro videos.

In winex11 we now request window state changes asynchronously and in
particular we request WM_STATE Withdrawn in this case when SetWindowPos
is called after removing WS_VISIBLE.

When WM_SETREDRAW 1 is called we also try updating the window state as
it should be made visible again, but this often happens too quickly and
the window manager hasn't yet updated the WM_STATE property, so we delay
the request until a later call to WindowPosChanged or until the reply is
received.

As the game doesn't process its window messages, ProcessEvents is then
never called with the right mask and the WM_STATE update is never seen.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59069
---
 dlls/win32u/input.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/dlls/win32u/input.c b/dlls/win32u/input.c
index 7ba5b97fbc2..6c7828bc41b 100644
--- a/dlls/win32u/input.c
+++ b/dlls/win32u/input.c
@@ -800,7 +800,7 @@ SHORT WINAPI NtUserGetAsyncKeyState( INT key )
 
     if (key < 0 || key >= 256) return 0;
 
-    check_for_events( QS_INPUT );
+    check_for_events( QS_ALLINPUT );
 
     while ((status = get_shared_desktop( &lock, &desktop_shm )) == STATUS_PENDING)
         state = desktop_shm->keystate[key];
-- 
GitLab

https://gitlab.winehq.org/wine/wine/-/merge_requests/9737