When two sends are performed in parallel on a socket the send which came second to server's (socked_send) will always considered blocking if the first send hasn't performed set_async_direct_result() in client's ntdll yet. Similarly, if select() is coming shortly after send() it may report socket as not write ready. We don't care for avoiding a race here because if those two sends or send / select are not synced by app it is unlikely possible for an app to depend on which gets processed first, and the one which was called earlier in wall time now also is not guaranteed to be actually processed first.
The patches fix Tekken 8 which gets frequently disconnected from multiplayer matches. The game treats WSAEWOULDBLOCK from send() on its non-blocking UDP socket, as well as the same socket not reported as write ready from select as a disconnection condition. Those conditions normally (outside of actual network problem / contention) only happen due to the races described above (while the game performs send() concurrently from different threads or is racing send with select).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4967
--
v2: mshtml/tests: Test builtin function default value getter with custom
mshtml: Expose the IHTMLEventObj5 props to scripts.
mshtml: Implement `initMessageEvent` for MessageEvents.
mshtml: Implement `origin` prop for MessageEvents.
mshtml: Implement `data` getter for MessageEvent objs.
mshtml: Implement `source` prop for MessageEvents.
mshtml: Use a hook to implement postMessage.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4986
As _WINE_HWND_STYLE and _WINE_HWND_EXSTYLE respectively.
Gamescope parses these to make smarter decisions about what window
to primary focus, or to treat as a dropdown/overlay.
This was originally a Proton commit by Remi Bernon, however,
it would definitely be nice to have support for Gamescope focusing
correctly under upstream Wine as well.
Fixes a bunch of games/launchers run with Wine under Gamescope.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2902
An alternative approach to `EnumAdapters2` that does not directly call to GDI driver and therefore does not require GDI driver functions to be expanded. The implementation now lives in `sysparams.c` to make it closer to win32u caches it accesses. It still uses `OpenAdapterFromLuid` internally because that's where adapter handles are actually assigned and to make sure returned handles are usable with other functions that rely on GDI driver being aware of what the handle represents to be able to function correctly (like `QueryVideoMemoryInfo`).
See !4791 for some background and why this version might be preferable over the one submitted there.
--
v5: win32u: Implement NtGdiDdDDIEnumAdapters2.
win32u: Maintain a list of GPUs in cache.
gdi32,win32u: Add stubs for D3DKMTEnumAdapters2 and NtGdiDdDDIEnumAdapters2.
gdi32/tests: Add D3DKMTEnumAdapters2 tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4857
This serie mainly tackles the playback of wave tracks with loops.
Current code had to be improved as:
- loop playback doesn't require setting the loop start/end points:
leaving them at 0 mean playing the whole segment,
- moreover, the length (at least for wave tracks) of the segment
is not used. Instead, the duration of stamped/posted tracks is
used instead.
- even forcing a length on segment isn't taken into account (tested
locally, but not included in the current tests).
- implemented it by creating the graph internal to segment state
and gathering relevant information on the fly. There's no
indication it's done this exact way on native, but at least
tests for time of track playback are identical.
Notes:
- only changed the track waves, future work will require equivalent
testings at least on MIDI sequences.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4981