I began working on this to address some flakyness (see e.g. https://gitlab.winehq.org/wine/wine/-/jobs/183916), and eventually I ended up rewriting `test_capture()` because the previous implementation looked somewhat incomplete.
--
v6: mmdevapi/tests: Check that the received packet isn't larger than the padding.
mmdevapi/tests: Check that GetBuffer() returns a packet of the expected size.
mmdevapi/tests: Check that GetBuffer() fails when no packet is available.
mmdevapi/tests: Introduce a helper to read many packets when capturing.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8862
When running `SymInitializeW(GetCurrentProcess(), NULL, TRUE)` in a 32-bit EXE on 64-bit macOS, there are a number of syscall faults resulting from 64-bit pointers being truncated to 32 bits and then passed to `ReadProcessMemory()`. Fix these, mostly by widening variables to 64 bits.
--
v2: dbghelp: Don't try to load 64-bit ELF/Mach-O debug info in a Wow64 process.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8962
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8869
I think this would be a much lighter and less complicated approach than trying to wake the window threads with internal messages. And it should be able to avoid spurious wake ups when there's no window surfaces involved.
What I'm not completely sure about is whether this is going to flush the surfaces frequently enough, and if we can assume the window thread will always either peek or wait for messages.
--
v2: win32u: Keep window surfaces in a per-thread linked list.
win32u: Remove window surface flush in expose_window_surface.
win32u: Remove window surface flush on lock / unlock.
win32u: Remove some less useful flush_window_surfaces.
win32u: Flush window surfaces while waiting for messages.
win32u: Use an absolute wait timeout in wait_message.
win32u: Remove unnecessary window_surface exports.
win32u: Dispatch NtUserUpdateLayeredWindow to the owner thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8965
Every 33ms on toplevel windows with a non-dummy, non-offscreen window surface.
Making sure the window surfaces are flushed from their owner thread instead of any other thread that might draw to it and trigger an occasional flush. This removes the need for tracking window surfaces to additionally flush them in win32u.
It will make it easier to implement GL-based window surfaces for compositing, and simplify context management. Instead of one context per window, made current on the flushing thread we can have a single context on each thread owning a window that is used to flush them.
--
v2: win32u: Remove now unnecessary window surfaces list.
win32u: Flush window surfaces in process_wine_present.
server: Post a WINE_WM_PRESENT for window surface present.
win32u: Remove unnecessary window_surface exports.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8869
Instead of https://gitlab.winehq.org/wine/wine/-/merge_requests/8869
I think this would be a much lighter and less complicated approach than trying to wake the window threads with internal messages. And it should be able to avoid spurious wake ups when there's no window surfaces involved.
What I'm not completely sure about is whether this is going to flush the surfaces frequently enough, and if we can assume the window thread will always either peek or wait for messages.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8965
This manifested with https://gitlab.winehq.org/wine/wine/-/merge_requests/8875, as it adds fd_cache_mutex lock on thread init to receive the new inproc sync file descriptors. The kernel32:sync test creates a thread then immediately terminates it, which causes wineserver to close its pipe while it is initializing, triggering a SIGPIPE that is receive while the thread is within the server_init_thread call and request.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8878