July 2026 - Wine-GitLab - list.winehq.org

[PATCH v8 0/3] MR11249: Implement sprite batches.
by Santino Mazza (＠tati) Aug. 13, 2026

Aug. 13, 2026

-- v8: d2d1: Implement transform matrixes for sprite batches. d2d1: Implement sprite batches. https://gitlab.winehq.org/wine/wine/-/merge_requests/11249

3 5

[PATCH 0/2] MR11420: mfplat: Implement d3d12-backed buffers.
by Charlotte Pabst (＠CharlottePabst) Aug. 13, 2026

Aug. 13, 2026

Follow-up to !9777 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11420

4 31

[PATCH v3 0/2] MR10712: wineandroid: fix desktop sizing and repaint on resolution changes
by Twaik Yont (＠twaik) Aug. 12, 2026

Aug. 12, 2026

This series fixes two related issues in wineandroid affecting desktop initialization and repaint behavior when using the virtual desktop mode. First, launching explorer.exe with an empty desktop size ("/desktop=shell,,android") does not behave as intended on wineandroid. When the size is omitted, explorer attempts to determine the desktop resolution via get_default_desktop_size(). If no matching registry entry is found, it falls back to a hardcoded default (typically 800x600). Later, even if the wineandroid backend sets the correct display size through pCreateDesktop, explorer overrides it again during initialize_display_settings(), restoring the default resolution. As a result, the desktop ends up stuck at 800x600 regardless of the actual display size reported by the backend. To address this, the desktop is now launched with a size of "-1x-1". This value is accepted by parse_size(), but does not correspond to a valid resolution. As a result, explorer does not fall back to the default resolution, and also avoids overriding the backend-provided size during initialization. This allows the desktop to retain the correct resolution as configured by wineandroid. Second, window repainting on resolution changes is fixed. Previously, WM_ANDROID_REFRESH used NtUserExposeWindowSurface(), which only exposes existing surface contents without invalidating the window. This prevents WM_PAINT and WM_ERASEBKGND from being generated. When the desktop or other windows are resized (e.g. after applying a new display mode), they may retain stale contents instead of repainting. This is resolved by replacing NtUserExposeWindowSurface() with NtUserRedrawWindow(), ensuring proper invalidation and repaint of window contents. This fixes cases where the desktop background is not redrawn after a resolution change. Together, these changes ensure that the desktop starts with the correct resolution and that windows are properly repainted when display settings change. -- v3: wineandroid: Re-apply the real screen resolution after explorer clobbers it. https://gitlab.winehq.org/wine/wine/-/merge_requests/10712

3 9

[PATCH v2 0/3] MR11174: mfreadwrite: Fix race condition resulting in ReadSample never completing
by Yuxuan Shui (＠yshui) Aug. 12, 2026

Aug. 12, 2026

mfreadwrite: Set the reader SEEKING flag early. Previously the SEEKING flag is only set when the ASYNC_SEEK operation is executed. This is too late because of this race condition: - Application calls SetCurrentPosition, which queues the ASYNC_SEEK operation but does not set SEEKING. - Application calls ReadSample. Since the SEEKING flag hasn't been set, it proceeds without waiting and queues an ASYNC_READ operation. - ASYNC_SEEK operation starts its execution, but hasn't reached IMFMediaSource_Start yet. - ASYNC_READ operation starts its execution, and calls IMFMediaStream_RequestSample. Media source queues a request sample job. reader->streams[i]->requests++. ASYNC_READ finishes. - ASYNC_SEEK operation calls IMFMediaSource_Start, the request sample job queued by the media source gets dropped. At this point, there is no request sample job running, but the stream->requests counter is still positive. From this point on the source reader will not request anymore samples, future ReadSample will never complete. Setting the SEEKING flag early, then source reader will always wait in ReadSample so this kind of ordering cannot happen. I used a arbitrary 100 iterations in the test case, because there is really no good way to introduce delays to trigger this race condition predictably. Because it all depends on how the work queue schedules its jobs and I can't stub out the work queue. In my testings the current source reader usually hangs after 2/3 iterations. -- v2: mfreadwrite: Set the reader SEEKING flag early. mfreadwrite/tests: Test some async source reader behaviors. mfreadwrite: Fix segfault in ReadSample error path. https://gitlab.winehq.org/wine/wine/-/merge_requests/11174

3 8

[PATCH v2 0/4] MR11495: quartz: Emulate fullscreen mode in render graph when renderer does not support it.
by Paul Gofman (＠gofman) Aug. 12, 2026

Aug. 12, 2026

-- v2: quartz: Implement entering and leaving emulated fullscreen mode. quartz: Introduce fullscreen mode emulation in filtergraph. quartz: Implement BaseControlWindowImpl_GetRestorePosition(). quartz/tests: Add tests for implicit fullscreen support by filter graph. https://gitlab.winehq.org/wine/wine/-/merge_requests/11495

4 6

[PATCH 0/2] MR10975: winegstreamer: Initialise a maximum of 30 samples for the video decoder/processor.
by Conor McCarthy (＠cmccarthy) Aug. 12, 2026

Aug. 12, 2026

The number of output samples which may be queued in the decoder can depend on the number of threads used. A requirement of 24 has been observed, but 30 provides a buffer for edge cases. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10975

2 3

[PATCH 0/18] MR11520: quartz/tests: Add tests for the DirectShow Color Space Converter filter.
by Brendan McGrath (＠redmcg) Aug. 12, 2026

Aug. 12, 2026

This MR adds tests for the DirectShow Color Space Converter filter in preparation for its implementation. This is reworked version of MR !11432, it looks to address the feedback that was made there. -- This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/11520

2 1

[PATCH v4 0/3] MR11346: dxva2: Implement DXVA2 decoder capability queries via VA-API.
by Valerian Mayega (＠valerian) Aug. 12, 2026

Aug. 12, 2026

GetDecoderDeviceGuids, GetDecoderRenderTargets and GetDecoderConfigurations were E_NOTIMPL stubs, the root cause of hardware video decode never working through the legacy DXVA2 API (apps fall back to software decode after the first negotiation call fails). Query VA-API directly for supported profiles and report the matching DXVA2 GUIDs (H.264, HEVC Main/Main10) and render target formats, mirroring the equivalent D3D11/Media Foundation path Wine already supports via winegstreamer. Signed-off-by: Valerian Mayega <valerian(a)gmail.com> -- v4: dxva2: Implement HEVC decode (CreateVideoDecoder and Execute). https://gitlab.winehq.org/wine/wine/-/merge_requests/11346

3 7

[PATCH 0/5] MR2243: dcomp: Add IDCompositionDevice2 stub.
by Zhiyi Zhang (＠zhiyi) Aug. 11, 2026

Aug. 11, 2026

Note that IDCompositionDevice2 is not inherited from IDCompositionDevice. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2243

4 8

[PATCH v2 0/2] MR2245: dxgi: Implement IDXGIFactory2::CreateSwapChainForComposition().
by Zhiyi Zhang (＠zhiyi) Aug. 11, 2026

Aug. 11, 2026

-- v2: dxgi: Implement IDXGIFactory2::CreateSwapChainForComposition(). dxgi/tests: Add composition swapchain tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/2245

5 9