[PATCH v2 0/1] MR9737: win32u: Process every driver event in NtUserGetAsyncKeyState.
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
From: Rémi Bernon <rbernon@codeweavers.com> 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
participants (1)
-
Rémi Bernon